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

[Luther Martin]

Comments in-line:

> On Thu, Oct 2, 2008 at 5:19 PM, Luther Martin <martin at voltage.com>
> wrote:
> > 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).
>
> I just checked all of those, and none of them define a media type
> parameter whose job is to identify the logical recipient of the
> message.

This is certainly true, but they do define media types for cryptographic keys and related information, which is the proposed use of application/ibe-key-request and application/ibe-pkg-reply. The application/ibe-key-request is used much like the application/pkcs10 and the application/ibe-pkg-reply is used much like an application/pkcs7-mime type: the first of the two is used for a certificate signing request and the second is used for the resulting certificate. In the case of this draft, one media type is used for a private key request and another for the resulting private key.

>
> > And the use of HTTP seems consistent with its use in other
> cryptographic protocols, like those defined in RFC 2510, for example.
>
> Section 5.4 of 2510 says;
>
>    This MIME object can be sent and received using common HTTP
>    processing engines over WWW links and provides a simple browser-
>    server transport for PKIX-CMP messages.
>
> Which I interpret to be consistent with my description of the proper
> use of HTTP.

The most recent relevant PKIX document seems to be RFC 5273. Section 4 of this doc (HTTP/HTTPS-Based Protocol) even begins "This section describes the conventions for the use of HTTP [HTTP] as a transport layer." This seems to indicate to me that it's accepted practice in similar protocols. (This is used in all shipping products that I know of, but that's probably irrelevant.)

>
> > 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.
>
> I don't understand the difference, but I'm not suggesting all
> information need be in the URI, only identifying information.  There
> are also other places where other information can be located in an
> HTTP message (other than the URI or media type parameters, e.g. HTTP
> header).

The requirement to define media types for application/ibe-pp-data, etc., came up during the last call for the internet draft that we're discussing, so people who are wiser than me seem to think that this is a good idea. I'm just deferring to their judgment.

The alternative is to use a more generic media type, perhaps application/xhtml+xml, which might cause problems with traversing firewalls, etc. That was deemed inappropriate for this particular use, so we applied for the three media types that we're discussing here.

> >
> > 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.
>
> Yes, using a certificate would be problematic.  But I could imagine
> using the certificate fingerprint in the URI, and then using GET upon
> that.

That's certainly possible, but that's not proposed in the current internet draft. The protocols defined in the draft work entirely differently.