See an updated proposal for CertUID at the end of this E-mail.
Ambarish Malpani wrote:
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.
I would disagree with this, unless "issuer" is a FDN in the X.521 sense.
So the question is: how does one uniquely identify an issuer.
This is not the right question. :-(
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.
DN can clash when they are RDNs (Relative Distinguished Names).
There really is no way of enforcing uniqueness is issuer DNs all
over the world.
Correct.
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.
OK.
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).
The problem to consider is an empty DN and the use of an issuerAltName.
The issuerAltName and the CertificateSerialNumber do not necessarily
identify uniquely a certificate unless some additional assumptions are
made on the structure of the issuerAltName.
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.
Hold on a second. You suppose an upstream problem already solved !
If you get a signed message, you may need to identify who signed it and
with which certificate. The structure you propose below does not allows
this, unless by some magic you get an hint.
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.
But it does help the requester :-)
See also the response I sent today to Carlisle, where I raise the basic
question on the means to identify the right OCSP. If that question is
solved, then your problem is also solved. However, I do not claim that
the answer to that question is unique or easy. :-)
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
There has been a proposal to make the certificateHash optional. If the
issuerDN is a FDN, then the certificateHash is not needed, so this is a
good reason. If the issuerAltName has some form of hierarchy that
allows it to be unambiguous, in the same way the certificateHash is not
needed. In all the other cases, it is needed.
I would thus propose the following structure :
CertUID ::= SEQUENCE {
issuerDN Name,
issuerAltName IssuerAltName OPTIONAL, -- As defined in PKIX
serial CertificateSerialNumber,
certificateHash CertHash OPTIONAL
}
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