Richard Levitte - VMS Whacker wrote:
>
> michael> > the same way it should be done according to RFC2560...
> michael>
> michael> OCSP does almost nothing with the issuerName.
>
> Have you read RFC2560 properly? You can have responders that answer
> for other CA's. Multiple CA's even.
I know that. But is the DER-encoding of the issuerName always the
same?
Name ::= CHOICE {
RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::=
SET OF AttributeTypeAndValue
^^^^^^
IMHO at least this type definition containing SET OF might lead to
different DER-encodings (and therefore different issuerNameHash
values) of equivalent issuer names if the RelativeDistinguishedName
is reordered. The CertID also contains issuerKeyHash and this can be
used to determine the issuer cert. But what is an OCSP responder
supposed to do if issuerNameHash does not match?
Well, RFC2560 could avoid these problems by stating that the DER
encoding of the issuer's DN should be taken directly from the
issuer's certificate to calculate the hash. And the OCSP client must
not reorder RelativeDistinguishedName and produce its own DER
encoding.
Can somebody with real OCSP experience say anything about this?
Ciao, Michael.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
