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

[Mark Baker]

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.

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

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

Mark.