Denis:
The syntax from RFC 2634 is:
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
The "improved" syntax that you reference from RFC 3126 is:
OtherCertID ::= SEQUENCE {
otherCertHash OtherHash,
issuerSerial IssuerSerial OPTIONAL
}
OtherHash ::= CHOICE {
sha1Hash OtherHashValue, -- This contains a SHA-1 hash
otherHash OtherHashAlgAndValue
}
OtherHashValue ::= OCTET STRING
OtherHashAlgAndValue ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashValue OtherHashValue
}
This seems more complicated than necessary to me.
Why not use:
ESSCertIDv2 ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier DEFAULT id-sha1,
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
I prefer this approach because it is always fewer octets, and it
generates the same ESSCertID output when SHA-1 is used.
Russ
At 08:43 AM 11/8/2005, Denis Pinkas wrote:
>Jim Schaad presented a concern about the algorithm flexibility of the
>ESSCertID field. Right now this field is limited to the use of the SHA-1
>algorithm, and Jim proposed the addition of an AlgorithmIdentifier to
>indicate the digest algorithm used to prepare the digest.
OtherSigningCertificate, as defined in RFC 3126, could be used for
that purpose
id-aa-ets-otherSigCert OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 19 }
RFC 3126 was anticipating the need to use other algorithms.
Denis