[Top] [All Lists]

TR: Request change in son-of-rfc2633

2003-10-29 02:07:10

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.

-----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 
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
     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.


  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 
unambiguous identifier for certs:

  certIdentifier [1] 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 
requirements, which
says that the "sid specifies the signer's certificate", which 
the certID
certainly does.


<Prev in Thread] Current Thread [Next in Thread>