RE: Request change in son-of-rfc2633

[[e-mail] (Peter Gutmann)]

Russ Housley <[e-mail]> 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.