Re: [media-types] review requested: draft-turner-application-cms-media-type

[Sean Turner <[e-mail]>]

On 6/13/13 6:34 AM, Bjoern Hoehrmann wrote:
> * Sean Turner wrote:
>> In case I'm just supposed to sending the template:
>> Optional parameters:
>>
>>    encapsulatedContent=y; where y is one or more CMS ECT
>>    (Encapsulating Content Types); multiple values are encapsulated in
>>    quotes and separated by a folding-whitespace comma folding-
>>    whitespace.  ECT values are based on content types found in
>>    [RFC3274], [RFC4073], [RFC5083], [RFC5652], and [RFC6032].  This
>>    list can later be extended see Section 3.
>
> I think the first "ECT" should be "ECTs"; I can't parse the part after
> the semicolon. There should probably be a comma before "see". Same for
> the next parameter.

Fixed.

>> Security considerations:
>>
>>    See [RFC3370], [RFC5652], [RFC5753], and [RFC5754] for id-
>>    signedData, id-envelopedData, id-digestData, id-encryptedData, id-
>>    ct-authData; see [RFC5958], [RFC5959], and [RFC6162] for id-ct-KP-
>>    aKeyPackage; see [RFC6031] and [RFC6160] for id-ct-KP- sKeyPackage;
>>    see [RFC6032], [RFC6033], and [RFC6161] for id-ct-KP-
>>    encryptedKeyPkg; see [RFC5914] for id-ct-trustAnchorList; see
>>    [RFC3274] for id-compressedData; see [RFC5083] and [RFC5084] for
>>    id-ct-authEnvelopedData; see [RFC4073] for id-ct-contentCollection
>>    and id-ct-contentWithAttrs; see [RFC4108] for id-ct-
>>    firmwarePackage, id-ct-firmwareLoadReceipt, id-ct-
>>    firmwareLoadError; see [ID.housley-keypackage-receipt-n-error] for
>>    id-ct-KP-keyPackageReceipt and id-ct-KP-keyPackageError.
>
> Editorially the above is quite horrible, maybe a table to map the values
> to the RFCs would be better. Also, there should be some prose to set the
> context here (why would one "see" all the referenced documents, and why
> are there no security considerations for the type right here, beyond the
> suggestion to look elsewhere).

These are a list of all the RFCs where these content types are defined 
plus the documents that define algorithms that can be used to protect 
the content types.  There was one additional consideration in the draft 
that didn't end up in the template so how about:

Security Considerations:

The following security considerations apply:

RFC       | CMS Protecting Content Type and Algorithms
----------+-------------------------------------------------
[RFC3370] | id-signedData, id-envelopedData, id-digestedData,
[RFC5652] | id-encryptedData, and id-ct-authData
[RFC5753] |
[RFC5754] |
----------+-------------------------------------------------
[RFC5958] | id-ct-KP-aKeyPackage
[RFC5959] |
[RFC6162] |
----------+-------------------------------------------------
[RFC6031] | id-ct-KP-sKeyPackage
[RFC6160] |
----------+-------------------------------------------------
[RFC6032] | id-ct-KP-encryptedKeyPkg
[RFC6033] |
[RFC6161] |
----------+-------------------------------------------------
[RFC5914] | id-ct-trustAnchorList
----------+-------------------------------------------------
[RFC3274] | id-compressedData
----------+-------------------------------------------------
[RFC5083] | id-ct-authEnvelopedData
[RFC5084] |
----------+-------------------------------------------------
[RFC4073] | id-ct-contentCollection and
           | id-ct-contentWithAttrs
----------+-------------------------------------------------
[RFC4108] | id-ct-firmwarePackage, id-ct-firmwareLoadReceipt,
           | and id-ct-firmwareLoadError
----------+-------------------------------------------------
[RFCTBD]  | id-ct-KP-keyPackageReceipt and
           | id-ct-KP-keyPackageError
----------+-------------------------------------------------

In some circumstances, significant information can be leaked by 
disclosing what the innermost ASN.1 structure is.  In these cases it is 
acceptable to disclose the wrappers without disclosing the inner content 
type.