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.
Regards.
-----Message d'origine-----
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
Gutmann
Envoyé : mercredi 29 octobre 2003 05:51
À : blake(_at_)brutesquadlabs(_dot_)com; housley(_at_)vigilsec(_dot_)com;
jimsch(_at_)exmsft(_dot_)com;
pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz
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
about it.
2. Cert found, bad signature, although there may be one out
there that
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.
or:
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
arbitrarily large
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
guaranteed-
unambiguous identifier for certs:
certIdentifier [1] OCTET STRING SIZE(20),
(being the almost universally-used SHA-1
hash/fingerprint/thumbprint/whatever
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
requirements, which
says that the "sid specifies the signer's certificate", which
the certID
certainly does.
Peter.