[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OCSP - Public Key Dstribution
Anders Rundgren a écrit:
> Salut Denis,
This sounds a little bit familiar to me. :-(
Please do not mix French and English.
> Pardon my ignorance but does a returned issuerKeyHash give you the
> possibility to verify a certificate signature *after* its status has been checked?
Yes.
> Don't you need the original (unhashed) issuer public key to to that?
You can get it after the OCSP request.
> I.e. does this enhanced OCSP draft essentially support my
suggested OCSP++
> (previously I called it OCVP) system *without* requiring extensions? That would be
> just fantastic!
I took a look at the URL address you are providing. Since the
description is pretty short, it is hard to answer your question.
However the text says "an easy-to-use system for checking status
and validity of a certificate." In this version of OCSP, there is
no intent for checking the validity of the certificate but only its
revocation/on-hold status. Checking the status would be far more
complicated and controversial.
Denis
> http://www.jaybis.com/specifications/pkix/ocsp.html
>
> Please enlighten me!
>
> Regards
> Anders Rundgren
>
> ----------
> From: Denis Pinkas [SMTP:Denis.Pinkas@bull.net]
> Sent: Saturday, September 19, 1998 02:15
> To: Andreas Berger
> Cc: Peter Sylvester; ambarish@valicert.com; ietf-pkix@imc.org
> Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt
>
> Andreas,
>
> I share your concerns.
>
> The current definition of CertId is as follows:
>
> CertID ::= SEQUENCE {
> hashAlgorithm AlgorithmIdentifier,
> issuerNameHash OCTET STRING, -- Hash of Issuer's DN
> issuerKeyHash OCTET STRING, -- Hash of Issuers public
> key
> serialNumber CertificateSerialNumber }
>
> CertID is used both in the request and in the response.
> I would suggest to change it to:
>
> CertID ::= SEQUENCE {
> hashAlgorithm AlgorithmIdentifier,
> issuerNameHash OCTET STRING, -- Hash of Issuer's DN
> issuerKeyHash OCTET STRING OPTIONAL, -- Hash of
> Issuers public key
> serialNumber CertificateSerialNumber }
>
> making the issuerKeyHash optional.
>
> The issuerKeyHash would be optional for a request but mandatory for
> a response. The rational is as follows: the requester needs "at
> some time" to get the public key of the issuer in order to verify
> the certificate. If we mandate that field to be always present
> thent it must get it *before* the request to the OCSP server. If we
> make it optional, then it may get it before or after the request to
> the OCSP server. This gives some flexibility, without too many
> options.
>
> The OCSP server should anyway have the Issuers public key and thus
> its hash. The hash may allow the requester to disambigous some
> responses in case of anonymity.
>
> Denis
>
> > I agree with this discussion and would like to add some thoughts:
> >
> > Peter Sylvester wrote:
> > > > I actually think OCVP is a bigger thing than just making the hash
> > > > of the issuer's PUBLIC key NULL. That whole topic should be
> > > > addressed at one shot
> > > >
> > > I am *not* really talking about OCVP, I am talking about 'CertID',
> > > a short way to identify a certificate. The syntax
> > > for the identification should be flexible enough
> > >
> > > - not to require more than the original certificate in
> > > order to construct the identification.
> > The is a very good assumption. While the authority key *may* be
> > available, it certainly isn´t always available.
> >
> > > - to allow identification of a certificate in a given context
> > > ==> serial number for example or/and hash of cert
> > The serial number is a little bit weaker but supported by other parts of
> > X.509, PKIX and several mail protocols, using issuer/serial for
> > identification of a certificate. So issuer/serial or
> > issuer/certificate-hash look like valid combinations. It may be a good
> > idea to be able add a subject public key hash if necessary.
> >
> > > - to allow the OCSP provider to find the source of
> > > information provider.
> > > ==> name of issuer may be necessary, hash of issuer name
> > > may not be sufficient.
> > So for identification of issuer we probably have a choice of issuer-name
> > or issuer-hash, probably in combination with issuer-public-key or
> > issuer-public-key-hash as an optional parameter.
> >
> > > - to ensure that the creator of the certificate really has
> > > a copy of a cert.
> > > ==> hash of cert for example, or serialnumber if authority
> > > allocates them in a sparse way.
> > > If we assume that the orginal version of OCSP where it was
> > > possible to just have a cert did make sense, thus I do not
> > > see why there is a need for the issuer public key extract
> > > in the certID. At least it should be optional in some way.
> > >
> > > It seems useful to me to fix a syntax for CertID that
> > > is sufficiently open for extensions without requiring
> > > a new protocol version..
> >
> > The removal of the certificate proper as a means to "identify" a
> > certificate forced us to specify an extension to OCSP to do this
> > (transport the certificate in the request - optional, or in the reply -
> > optional). If the consensus is that OCSP should not be able to transport
> > the certificate proper, I think we should at least open the possibility
> > to transport a certitficate hash.
> >
> > That leads me back to the idea of making a lot of the identification
> > parameters in "CertID" optional. But we will get serious
> > interoperability issues. So either we build specific CertIDs with
> > specific purposes in mind or we need some profiling (and probably a
> > means for the responder to transport valid combinations back to the
> > client).
> >
> > Andreas
> > --
> > Fifty-three percent of Fortune 1000 executives think the
> > Arch Deluxe is something that helps to run a computer.
> > -- Jericho Communications
>
> --
> Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net
> Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
> 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
--
Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21