Re: [media-types] Update of MIME media type application/pkcs7-mime Registration

[Sean Turner <[e-mail]>]

On 6/13/13 10:25 AM, Sean Turner wrote:
> On 6/13/13 10:18 AM, Alexey Melnikov wrote:
>> On 13/06/2013 13:51, Sean Turner wrote:
>>> On 6/13/13 6:47 AM, Bjoern Hoehrmann wrote:
>>>> * Sean Turner wrote:
>>>>> The application/pkcs7-mime content type defines the optional "smime-
>>>>> type" parameter [RFC5751].  The smime-type parameter for Server-side
>>>>> Key Generation Response is server-generated-key.
>>>>>
>>>>> smime-type name: server-generated-key
>>>>>
>>>>> Required parameters: None
>>>>
>>>> This should be preceded by
>>>>
>>>>    Type name: application
>>>>
>>>>    Subtype name: pkcs7-mime
>>>>
>>>> If this is supposed to register the application/pkcs7-mime type. But it
>>>> seems to me that using the media type registration template here is not
>>>> correct, I would rather expect "Updates: 5751" and then simply defining
>>>> the additional smime-type parameter, no need for the template.
>>>
>>> It's not registering application/pkcs7-mime is adding a parameter. If
>>> I understand correctly, if we added "Updates: 5751 (once approved)" to
>>> the header we could just omit the template completely?  I'd argue that
>>> if we don't need the template that's great, but what's more important
>>> is that people be able to find these subtypes and the way to do that
>>> is to have them pointed to by the registry not the original document.
>>> How about if we just omit the template and ask IANA to *also* point to
>>> this document from the application/pkcs7-mime registry?
>> Sounds sensible to me. (But also see my other email).
>
> Other email is about using +der and adding some generic considerations
> about parsers.  I'll have to go check on the +der bit with some folks
> but the other suggestion seems very reasonable.

I don't think we can put +der at the end of this because the others 
don't include it.  But on the security considerations how about the 
following:

ASN.1 encoding rules (e.g., DER and BER) have a type-length-value 
structure, and it is easy to construct malicious content with invalid 
length fields that can cause buffer overrun conditions. ASN.1 encoding 
rules allows for arbitrary levels of nesting, which may make it possible 
to construct malicious content that will cause a stack overflow. 
Interpreters of ASN.1 structures should be aware of these issues and 
should take appropriate measures to guard against buffer overflows and 
stack overruns in particular and malicious content in general.

spt