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

From: Chris Lonvick <[email-masked]>
Date: Sat, 10 Apr 2010 18:24:10 -0700 (PDT)

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.)

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.

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.

Regards,
Chris

---

From: Sean Turner <[email-masked]>
Date: Mon, 12 Apr 2010 13:20:38 -0400

Chris,

Thanks for your review.  Responses inline.

spt

Chris Lonvick wrote:
> 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.
> 
> Not finding anything of particular importance to note about the 
> concepts, I started looking at the nits.
> 

I'll r/means/mechanisms

> 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.

> Considerations ection even if it is just to say that nothing needs to be 

I'll delete the second sentence.

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 12 Apr 2010 10:42:42 -0700 (PDT)

Hi Sean,

All looks good.  One comment in-line.

On Mon, 12 Apr 2010, Sean Turner wrote:
> 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.

You're on the same track as I was thinking, but I was thinking of 
something VERY much more generic.  From RFCs 2797 and 5273,

    Implementers of this protocol are strongly encouraged to consider
    generally accepted principles of secure key management when
    integrating this capability within an overall security architecture.

(Which is a nice way of saying, "Don't be utterly stoopid!" :-)

Thanks,
Chris

---

From: Sean Turner <[email-masked]>
Date: Mon, 12 Apr 2010 14:16:37 -0400

Chris Lonvick wrote:
>> 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.
> 

I'll add this to the beginning of the considerations.

spt