Review for media types: application/ibe-pp-data, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml

[Luther Martin]

Comments below.

> -----Original Message-----
> From: ietf-types-bounces at alvestrand.no [mailto:ietf-types-
> bounces at alvestrand.no] On Behalf Of Mark Baker

> It's not really germane to the media type registration, but since you
> ask ...  Perhaps Sean could forward these comments to SMIME.
>
> The draft as a whole does a very poor job at using HTTP, opting to use
> it as a transport protocol rather than a transfer protocol.  For
> example, it mints new IBE-specific error codes - including a "server
> error" code - and returns those in HTTP 200 response messages.
>
> Regarding the use of the media type parameters, on
> application/ibe-key-request+xml, they are defined as;
>
> "The required parameters are the
>   identity for which an IBE private key is being requested
>   and an object identifier that identifies which
>   cryptographic algorithm the key is being requested for."
>
> In other words, it identifies the logical target of the request
> message, which, for HTTP, is supposed to be placed in the Request-URI
> field of the HTTP envelope.  HTTP GET should also be used to retrieve
> it, rather than HTTP POST which is the only allowed method per the
> draft.
>
> I also notice that RFC 3205/BCP 56 isn't referenced.
>
> Mark.

I'm not sure that I understand what the issue here is.

The definition and use of these media types is very similar to the definition and use of other media types that are used in cryptographic protocols. These include application/pkcs10 (RFC 2311), application/pkcs7-mime (RFC 2311), application/pkcs7-signature (RFC 2311), application/pkix-cert (RFC 2585), application/pkixcmp (RFC 2510) and application/pkix-crl (RFC 2585).

And the use of HTTP seems consistent with its use in other cryptographic protocols, like those defined in RFC 2510, for example.

The rationale behind using a POST for a private key request is that all of the information needed for the response isn't necessarily included in the URI.  On the other hand, all of this information is in the URI for a public parameter request, so a GET is more appropriate.

An IBE identity is just a string (which is eventually used as an input into a hash function). It's roughly like the public key that's used in other types of public key algorithms. I can't imagine a situation where you'd send a certificate request or certificate in the Request-URI field of the HTTP envelope, for example, which is analogous to what's being defined here.