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

From: Sean Turner <[email-masked]>
Date: Mon, 10 Jun 2013 10:58:18 -0400

Please review the following update to application/pkcs7-mime media type 
request which is documented in:
https://datatracker.ietf.org/doc/draft-ietf-pkix-est/
It adds an optional smime-type parameter.
The document is currently in IETF LC.

Thanks,

spt
---

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

Optional parameters: None

Encoding considerations: binary;

Security Considerations:

   Clients request a server provided key.  The request/response
   SHOULD be done in a TLS-protected tunnel.

Interoperability considerations: None

Published specification: This memo.

Applications which use this media type: Enrollment over Secure
Transport (EST)

Additional information:

   Magic number(s): None
   File extension: None
   Macintosh File Type Code(s):

Person & email address to contact for further information:

   Max Pritikin <[email-masked]>

Restrictions on usage: None

   Author: Max Pritikin <[email-masked]>

Intended usage: COMMON

Change controller: The IESG

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 13 Jun 2013 12:47:04 +0200

>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.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Sean Turner <[email-masked]>
Date: Thu, 13 Jun 2013 08:51:36 -0400

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

spt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 13 Jun 2013 15:18:05 +0100

On 13/06/2013 13:51, Sean Turner wrote:
> 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).

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 13 Jun 2013 15:24:50 +0100

On 10/06/2013 15:58, Sean Turner wrote:
> Please review the following update to application/pkcs7-mime media 
> type request which is documented in:
  [...]
>   File extension: None
.p7m ?

---

From: Sean Turner <[email-masked]>
Date: Thu, 13 Jun 2013 10:25:26 -0400

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

spt

---

From: Sean Turner <[email-masked]>
Date: Thu, 13 Jun 2013 10:46:00 -0400

> 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

---

From: Henrik Andersson <[email-masked]>
Date: Thu, 13 Jun 2013 22:54:04 +0200

> stack overruns in particular and malicious content in general.

Lots of formats have explicit length fields and nested structures.
Parsers are expected to know how to deal with malformed data of this type.

I don't think a warning of this kind is necessary, because if it was
then pretty much all formats requiring binary transfer considerations
(and then some!) would need it.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Jun 2013 11:02:31 +0100

> (and then some!) would need it.

More information is better, IMHO. At least calling out that this is DER/BER based would be a good idea.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Jun 2013 11:05:07 +0100

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

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

---

From: Sean Turner <[email-masked]>
Date: Fri, 14 Jun 2013 16:34:06 -0400

> The +suffix convention is a relatively new, but I think it should e used for all new registrations that match existing suffixes.

So it'd look like this:

Content-Type: application/pkcs7-mime+der; 
smime-type=server-generated-key; name=smime.p7m

I'm not sure this will work though.  The certs are definitly use DER and 
so would any signed attributes but the rest of need not be.

spt

---

From: Sean Turner <[email-masked]>
Date: Tue, 18 Jun 2013 05:42:07 +0900

On 6/15/13 5:34 AM, Sean Turner wrote:
>>> don't include it.
>> The +suffix convention is a relatively new, but I think it should e
>> used for all new registrations that match existing suffixes.
>
> So it'd look like this:
>

The more I think about adding +ber to the media type for this request 
the more it doesn't make sense to me.  This is not defining a new 
top-level media type nor a new sub-type it's defining a new optional 
parameter.  This might have not been clear now that I look back at the form:

OLD:

NEW:

   Optional parameters: smime-type name: server-generated-key

Adding +ber to application/pkcs7-mime doesn't seem to make sense to me 
because it would be retro actively changing a widely supported media 
type.  The other thing would be to use +ber but only when this optional 
parameter appeared and that also seems a bit odd to me.

spt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Jun 2013 11:35:57 +0100

On 17/06/2013 21:42, Sean Turner wrote:
> type.  The other thing would be to use +ber but only when this 
> optional parameter appeared and that also seems a bit odd to me.

One (or both) of us got confused. Of course it doesn't make sense to 
change existing MIME type. I was recommending use of +ber suffix for new 
MIME type registrations.

---

From: Sean Turner <[email-masked]>
Date: Tue, 18 Jun 2013 22:57:04 +0900

> change existing MIME type. I was recommending use of +ber suffix for new

Okay - roger might have been me.  Anyway that's another thread then ;)

But, I'll still ask the authors up the registration text as noted above 
with the old/new text.

spt