[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