Review for media types: application/ibe-pp-data, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml
martin at voltage.com
Fri Oct 3 02:45:28 CEST 2008
> On Thu, Oct 2, 2008 at 5:19 PM, Luther Martin <martin at voltage.com>
> > 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
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
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's certainly possible, but that's not proposed in the current internet draft. The protocols defined in the draft work entirely differently.
More information about the Ietf-types