[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
OCSP - Public Key Dstribution
Salut Denis,
Pardon my ignorance but does a returned issuerKeyHash give you the
possibility to verify a certificate signature *after* its status has been checked?
Don't you need the original (unhashed) issuer public key to to that?
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!
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