Review for media types: application/ibe-pp-data, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml
distobj at acm.org
Fri Oct 3 06:35:32 CEST 2008
On Thu, Oct 2, 2008 at 8:45 PM, Luther Martin <martin at voltage.com> wrote:
> Comments in-line:
>> 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.
I understand that there are similarities. My concern regards one of
>> > 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.)
It's not accepted practice, it's just (somewhat) common practice. For
many years, Web experts like myself have been pointing out that
protocols like that specified in RFC 5273 make inappropriate use of
HTTP, and in many cases, that there exists a generally superior
solution that uses HTTP properly. This is in large part why BCP 56
was authored. Unfortunately, it continues to be ignored by IETF WGs.
>> > 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.
I noticed 8-) I'm suggesting that would be superior solution to the
existing one. It would make the media type parameter unnecessary, put
the draft in "compliance" with BCP 56, and generally make the data
more easily accessible.
More information about the Ietf-types