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

[Alexey Melnikov <[e-mail]>]

On 13 Jun 2013, at 15:46, Sean Turner <[e-mail]> wrote:

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

There is no backward compatibility issue here, so I don't understand your argument.
The +suffix convention is a relatively new, but I think it should e used for all new registrations that match existing suffixes.

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

Works for me.