I like the "simpler" approach.
spt
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Russ Housley
Sent: Tuesday, November 08, 2005 1:02 PM
To: Denis Pinkas; ietf-smime(_at_)imc(_dot_)org
Subject: Re: flexibility of the ESSCertID field
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