Hi Denis,
I joined the SMIME mailing list just recently, so I am not certain
of the problem you guys are trying to solve. Let me explain the
issues in RCSP and the reasoning for choosing the method I have
for trying to uniquely identify a cert:
In RCSP, a client is sending over one or more certificates to an
RCSP responder, to check their revocation status.
I think we all agree that issuer/serial is sufficient to uniquely
identify a certificate.
So the question is: how does one uniquely identify an issuer.
I submit that the DN is not enough, because it is possible for
the to be DN name clashes - either maliciously, or because two
groups don't talk to each other before they choose their names.
There really is no way of enforcing uniqueness is issuer DNs all
over the world.
However, public keys don't suffer from the problem of impersonation.
If somebody else claims to have the same public/private key as me,
it is easy to prove otherwise.
Therefore, we have chosen to use the issuerDN, issuerPublicKey
and CertificateSerialNumber to uniquely identify a cert. (I need
to add the issuerAltName also, as you have).
As an optimization, to reduce the size of a request, we ask the
requestor to hash the issuerDN and issuerPublicKey in the request
rather than sending all the bytes.
Adding the certificateHash in the CertUID doesn't help us identify
the cert at all, because as an RCSP responder, I don't have the
cert itself - so I can't verify the CertHash against anything.
As an aggregator of revocation data/CRLs from multiple CAs, we
would like to be able to accept all CRLs - including ones where
the DNs might clash.
Is the SMIME problem different from this one? Does the recipient
already have the certificate the sender is referring to?
Regards,
Ambarish
P.S. For those who haven't been actively following these groups,
my suggestion for cert identification is:
CertID ::= SEQUENCE {
issuerNameAndKeyHash Hash,
serialNumber CertificateSerialNumber,
}
IssuerNameAndKey ::= SEQUENCE {
issuerDN Name,
issuerAltName IssuerAltName OPTIONAL,
issuerPublicKey SubjectPublicKeyInfo
}
i.e. you identify a cert by the hash of the IssuerNameAndKey
and a serial number.
The hash includes the public key of the issuer - this prevents the
Banana Republic CA from impersonating our well beloved and well
trusted US CA ;-).
Ofcourse, if keeping the size of the request small is not important,
or the recipient might not be able to figure out the issuer from
the hash, it might make sense to send IssuerNameAndKey instead
of its hash.
Denis Pinkas wrote:
There is no final position yet, but it seems that we are going towards
the following structure:
CertUID ::= SEQUENCE {
issuerDN Name,
issuerAltName IssuerAltName OPTIONAL, -- As defined in PKIX
serial CertificateSerialNumber,
certificateHash CertHash
}
This allows the support of alternate names and the certificate hash
allows to make the difference between certificates that would be issued
by CAs having the same name.
In any case, I would recommend that the pkix group and the smime group
adopt the same structure.
Denis
--
Denis Pinkas Bull S.A.
mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)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
--
---------------------------------------------------------------------
Ambarish Malpani
Architect (650) 849-9880
ValiCert, Inc. ambarish(_at_)valicert(_dot_)com
3160 W. Bayshore Road http://www.valicert.com
Palo Alto, CA 94303