Re: [secdir] SECDIR review of draft-turner-encryptedkeypackagecontenttype-01

[Sean Turner <[e-mail]>]

Chris,

Thanks for your review.  Responses inline.

spt

Chris Lonvick wrote:
> Hi,
> 
> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the IESG. 
> These comments were written primarily for the benefit of the security 
> area directors.  Document editors and WG chairs should treat these 
> comments just like any other last call comments.
> 
> Overall, I do not see any particular security concerns.  The document 
> appears to be in good shape and ready for publication.
> 
> Not finding anything of particular importance to note about the 
> concepts, I started looking at the nits.
> 
> Section 1 - The following is an awkward sentence:
>    The Cryptographic Message Syntax (CMS) specification [RFC5652]
>    defines means to...
> Perhaps:
>    The Cryptographic Message Syntax (CMS) specification [RFC5652]
>    defines mechanisms to...
> (Means means so many different things.)

I'll r/means/mechanisms

> Section 1 also says:
>    This document also defines an unprotected attribute for use with one
>    of the key management options supported by the encrypted key package
>    content type.
> Not being a crypto geek, I'm left guessing which this is.  It's not 
> specifically called out in the document, and the implications of using 
> it are not called out in the Security Considerations section.

How about I replace that sentence with:

This document also defines an unprotected attribute, Content Decryption
Key Identifier, for use with EncryptedData.

WRT the use of the unprotected attribute: The attribute is used to
identify a key that was previously distributed.  This kind of mechanism 
is used in EcnryptedData as well as in certificates (e.g., subject key 
and authority key identifiers).  I looked for some wording from other 
RFCs that used this kind of mechanism that I could use in a security 
consideration.  But, I couldn't find any.  I'm thinking there's isn't 
any text because as long as people don't do something utterly stupid 
like use the actual key as the identifier there is no security 
consideration.

> Why are you asking the RFC Editor to remove the IANA Considerstions 
> section?  Maybe I missed it, but I havn't seen any discussion about not 
> having an IANA Considerations section if you don't have anything for the 
> IANA to do.  I can see Informational and Experimental RFCs not having 
> anything, but IMHO a Standards Track document should have an IANA 
> Considerations ection even if it is just to say that nothing needs to be 
> done.

I'll delete the second sentence.