[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PKIX-2 http



Russ Housley wrote:
> 
> Anil and Peter:
> 
> We need to agree the MIME type for returning an http resource, and I
> suspect that the ones we select will be used by Trevor in the e-mial
> document.
> 
> I propose that we define two types:
> 
>         application/pkix-cert
>         application/pkix-crl
> 
> I suggest the use of "pkix" insepad of "x509" so that an application
> can be
> assured that the PKIX Certificate and CRL Profile is followed.  I
> suspect
> that many programmers will implement to the PKIX profile, not the full
> generality of X.509.  If I am wrong, we wasted a lot of time
> developing a
> profile that will be ignored.
> 
> Anil, I do not see a reson to distinguish between user and CA
> certificates
> in the MIME type.  In your message, you proposed separate MIME types.
> Don't you think that the same software application will process the
> certificate?  If so. then the signed information inside the
> certificate
> should be used to determine if it is a CA certificate or a user
> certificate.
> 
> Russ

I'd suggest getting input from the current practitioners of this
kind of thing, particularly engineers at Netscape and Microsoft.

The MIME types I suggested were chosen because they are what is currently
in use, but my main point was to discourage use of a generic
(non-)type like "application/octet-string", which would definitely
not go over well.

In current implementations, the separate mime types are used to trigger 
different "importing" behavior.  I agree that it is possible to distinguish
CA and user certificates based on content later in the handling code.

It is not always as easy to distinguish end-entity certificates that
are intended for use by the importing entity and those for other entities
with whom the implementation must communicate (e.g. by secure e-mail).

One feasible scheme involves checking whether the public component matches
one of the private keys known by the implementation for the present
user, but I believe current implementations are using yet another mime type
to distinguish these.

This avoids the issue of whether the implementation already has or will
later have the key.  I think that nothing precludes proper treatment in both cases.

In short I don't object to Russ's suggestion, but one should
ask people who are doing this kind of thing already.

--a.

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:gangolli@StructuredArts.com
http://www.StructuredArts.com