Subject: [HOKEY] Optional data/key label: EMSK Document

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 16 Jul 2007 16:01:59 -0700

Hi,

One more comment on USRK. It seems that the doc is missing one of its most
important essences (or may be I missed it).

What separates one USRK from the next is really the "data" field (aside from
key label of course) and really the "op-data" that goes into its derivation.

The whole point of this document was to ensure cryptographic separation of
USRKs and security EMSK by restricting creation of USRKs. 

It is supposed to force people with specific usages to produce specs that
shows exactly what "op data" fields go into the derivations of that USRK and
then go to IANA and get specific assignments for the key labels. I am not
sure what part of Op data needs to be IANAized!! But it seems key labels are
something that need IANA numbers, no?

I think more text needs to go into section 3.4

R,

Madjid 

-----Original Message-----
From: Madjid Nakhjiri [mailto:[email-masked]] 
Sent: Monday, July 16, 2007 3:35 PM
To: 'Joseph Salowey (jsalowey)'; 'Narayanan, Vidya'; 'Charles Clancy'
Cc: 'Glen Zorn (gwz)'; 'Dondeti, Lakshminath'; 'Madjid Nakhjiri'
Subject: RE: EMSK Document

Hi Joe,

I looked at the document. I must say that as far as my issue is concerned,
we have not made any progress. While the document has text at many places
pointing to the DSRK-->DSUSRK alternative for deriving DSUSRK, including two
figures, there is no reference (except the note you added) to the
USRK-->DSUSRK alternative. In that sense I think the document is not
balanced. The comment you added at the end of section 4 

	"Note that usages may define  
       alternate ways to constrain specific keys to particular  
       administrative doamins, however it is recommended that usages attempt

       to follw the DSRK and DSUSRK derivation if possible so they can take

       advantages of the mechanisms being developed to manage and distribute

       the information required to generate these keys and the keys  
       themselves."
Is actually discouraging this alternative..

I think we should simply correct the pictures and text to add USRK-->DSUSRK
alternative and also deal with the technical consequences as we discussed
back before and at Prague..

BTW, these discussions really belong to the general mailing list.

R,

Madjid  

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Monday, June 18, 2007 11:44 PM
To: Narayanan, Vidya; Madjid Nakhjiri; Charles Clancy
Cc: Glen Zorn (gwz); Dondeti, Lakshminath
Subject: RE: EMSK Document

OK,  I tried to clean up some of the terminology to align with USRK as
the root and to address problems with the key derivation.  Hopefully
this is still close to the original.  I also included some text which I
believe captures some of Madjid's comments at the end of section 4.  I
think we are really close to something we can submit.  

If there are no substantial comments then I will submit this on
Wednesday.  We can also push out another revision on top of this one if
necessary.  

Cheers,

Joe

_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Mon, 16 Jul 2007 16:07:25 -0700

Section 8.1 Discusses IANA allocation of key labels.  

> Sent: Monday, July 16, 2007 4:02 PM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: Optional data/key label: EMSK Document
> 
> Hi,
> 
> One more comment on USRK. It seems that the doc is missing 
> one of its most important essences (or may be I missed it).
> 
> What separates one USRK from the next is really the "data" 
> field (aside from key label of course) and really the 
> "op-data" that goes into its derivation.
> 
> 
> The whole point of this document was to ensure cryptographic 
> separation of USRKs and security EMSK by restricting creation 
> of USRKs. 
> 
> It is supposed to force people with specific usages to 
> produce specs that shows exactly what "op data" fields go 
> into the derivations of that USRK and then go to IANA and get 
> specific assignments for the key labels. I am not sure what 
> part of Op data needs to be IANAized!! But it seems key 
> labels are something that need IANA numbers, no?
> 
> I looked at the document. I must say that as far as my issue 
> is concerned, we have not made any progress. While the 
> document has text at many places pointing to the 
> DSRK-->DSUSRK alternative for deriving DSUSRK, including two 
> I think we should simply correct the pictures and text to add 
> USRK-->DSUSRK alternative and also deal with the technical 
> consequences as we discussed back before and at Prague..
> 
> OK,  I tried to clean up some of the terminology to align 
> with USRK as the root and to address problems with the key 
> derivation.  Hopefully this is still close to the original.  
> I also included some text which I believe captures some of 
> Madjid's comments at the end of section 4.  I think we are 
> really close to something we can submit.  
> 
> If there are no substantial comments then I will submit this 
> on Wednesday.  We can also push out another revision on top 
> of this one if necessary.  
> 
> Cheers,
> 
> Joe
> 
>  
> 
> 
>

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 17 Jul 2007 12:19:39 -0700

Hi Joe,

Thanks for the pointer, I guess I did miss it. May be we should add a
reference to section 8.1 within sections 3.2 and 3.4.

Looking at 8.1 closer a few points come to mind:

1) Is there a benefit in allowing both "label-string" and
"label-string@specorg"? It would seem we could just use the latter. 

2) "It is up to each domain how it manages its local namespace". I think
"domain" here means the specorg and not the administrative domain in DSRK.
This could introduce some confusion. May be reword?

3)Also it would probably make sense to have each "specorg" register the
domain name with IANA, even if we are leaving label-string to that
organizations.

4) for ietf.org label-strings it would make sense if we require the
registration of label-string with IANA.

Madjid

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 17 Jul 2007 22:52:16 -0700

> Sent: Tuesday, July 17, 2007 12:20 PM
> Subject: RE: [HOKEY] RE: Optional data/key label: EMSK Document
> 
> Hi Joe,
> 
> Thanks for the pointer, I guess I did miss it. May be we 
> should add a reference to section 8.1 within sections 3.2 and 3.4.
> 
[Joe] Sure

> "label-string@specorg"? It would seem we could just use the latter. 
[Joe] For completeness it seemed good to cover both scenarios,  note
that "label-string" assignments require IETF consensus, while
"label-string@specorg" has lesser requirements (SPECIFICATION REQUIRED).

> 2) "It is up to each domain how it manages its local 
> namespace". I think "domain" here means the specorg and not 
> the administrative domain in DSRK.
[Joe] Yes 

> 3)Also it would probably make sense to have each "specorg" 
> register the domain name with IANA, even if we are leaving 
> label-string to that organizations.
>
[Joe] I don't believe that IANA handles domain names.  

> 4) for ietf.org label-strings it would make sense if we 
> require the registration of label-string with IANA.
> 
[Joe] yes, the current documents requires IETF CONSENSUS to allocate
these names.   The current text is a bit odd since it doesn't seem to
require a specification. 

> one of its 
> > most important essences (or may be I missed it).
> > 
> > separation of USRKs and security EMSK by restricting creation of 
> > USRKs.
> > 
> produce specs 
> > that shows exactly what "op data" fields go into the derivations of 
> > that USRK and then go to IANA and get specific assignments 
> for the key 
> > labels. I am not sure what part of Op data needs to be 
> IANAized!! But 
> > it seems key labels are something that need IANA numbers, no?
> > 
> > I looked at the document. I must say that as far as my issue is 
> > concerned, we have not made any progress. While the 
> document has text 
> >        administrative doamins, however it is recommended 
> that usages 
> > attempt
> > 
> >        to follw the DSRK and DSUSRK derivation if possible 
> so they can 
> > take
> > 
> with USRK as 
> > this is still close to the original.
> > I also included some text which I believe captures some of Madjid's 
> > comments at the end of section 4.  I think we are really close to 
> > something we can submit.
> > 
> > Wednesday.  We can also push out another revision on top of 
> this one 
> > if necessary.
> > 
> > Cheers,
> > 
> > Joe
> > 
> >  
> > 
> > 
> > 
>