Actually, I even wonder what guarantees that a iAndS is unique, as, as far as I
know, there is no unique LDAP repository (or anything else) for DNs, and each
one is only unique in the issuer's scope. By chance, it seems that the whole
system finally works, but mathematically, it does not: 2 different CAs may
issue 2 CA certs with the same subjectName, and these CAs may issue 2 certs
with the same serial.
De : owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]De la part de Peter
Envoyé : mercredi 29 octobre 2003 05:51
À : blake(_at_)brutesquadlabs(_dot_)com; housley(_at_)vigilsec(_dot_)com;
Cc : ietf-smime(_at_)imc(_dot_)org
Objet : RE: Request change in son-of-rfc2633
Russ Housley <housley(_at_)vigilsec(_dot_)com> writes:
So, if the first certificate located is not the right one, search for
another. If one is not located, then return an error.
Which error though? With iAndS, there are three possible outcomes:
1. Cert definitely not found.
2. Cert definitely found, bad signature.
3. Cert definitely found, good signature.
With sKID, this becomes:
1. Cert not found, although it may be out there somewhere
and we don't know
2. Cert found, bad signature, although there may be one out
would return a good signature but we don't know about it.
3. Cert found, good signature.
So should the "one is not located" error be:
The data has been tampered with by an attacker.
The data may or may not have been tampered with by an
attacker, it sort of
looks like it was but I can't really tell because there may
be some other
cert that I'm not aware of that indicates that it wasn't.
In the presence of an ambiguous identifier and a potentially
number of certs identified by it, it's not possible to return
a useful error
message to the user.
One simple solution to this problem would be to introduce a
unambiguous identifier for certs:
certIdentifier  OCTET STRING SIZE(20),
(being the almost universally-used SHA-1
your particular program calls it) and deprecate the sKID on
the grounds that
it can't provide the same semantics as iAndS does, while a
certID can. Note
that this would be completely in line with the RFC 3369
says that the "sid specifies the signer's certificate", which