Subject: RE: Request change in son-of-rfc2633

From: "Blake Ramsdell" <[email-masked]>
Date: Sun, 26 Oct 2003 17:53:42 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Gutmann
> Sent: Wednesday, September 17, 2003 6:21 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Request change in son-of-rfc2633
> 
> "Jim Schaad" <[email-masked]> writes:
> 
> >Messages that use this choice cannot be read by S/MIME v2 
> clients, but are
> >not to cause crashes in S/MIME v3.1 clients."
> 
> I'm having some trouble parsing this... does this mean the 
> RFC is specifying
> that S/MIME clients aren't allowed to crash?   How is this enforced?

The language that has been added is as follows:

S/MIME v3.1 implementations MUST allow for the use of the choice of
subjectKeyIdentifier in messages. Messages that use this choice cannot
be read by S/MIME v2 clients, and MUST be handled gracefully in S/MIME
v3.1 clients.

So I imagine that we're now chartered with enforcing them to be graceful
vs. enforcing them to not crash ;).

Blake

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 29 Oct 2003 16:30:10 +1300

"Blake Ramsdell" <[email-masked]> writes:

>"When looking up certificates using the subjectKeyIdentifier field, S/MIME
>agents MUST be prepared to handle multiple certificates that have the same
>subjectKeyIdentifier value gracefully."

That won't work if you only find the wrong cert using the sKID.  That is,
there are two certs with the given sKID, you get a perfect match on the one
that you can locate, but it's the wrong one.

The real problem here is that by building a spaghetti PKI (one that violates
the original X.509 design) you're subjecting yourself to a world of pain that
no amount of text in a standard can resolve.  So the only practical solution
would be to include a warning to say that everything works as required with a
conventional PKI, but all bets are off once you're in a spaghetti PKI
scenario, because the design was never intended to be used like that.  Might I
suggest:

  "The behaviour of S/MIME agents in a spaghetti PKI scenario is a
  ecumen^H^H^H^Hpolicy matter".

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 29 Oct 2003 17:51:22 +1300

Russ Housley <[email-masked]> 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.

---

From: "Alberti Antoine" <[email-masked]>
Date: Wed, 29 Oct 2003 10:07:00 +0100

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 : [email-masked]
> [mailto:[email-masked]]De la part de Peter Gutmann
> Envoyé : mercredi 29 octobre 2003 05:51
> À : [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc : [email-masked]
> Objet : RE: Request change in son-of-rfc2633
> 
> 
>

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 30 Oct 2003 17:05:15 +1300

Steve Hanna <[email-masked]> writes:

>Anyone who "reads the PKIX tea leaves" and thinks that it's fine to skip name 
>chaining checks in path validation needs to have their eyes checked. RFC 3280 
>says in many places that name chaining MUST be checked.

Uhh, I'm not sure who that was directed at, but if it was at me then I should 
point out that the tea leaves comment was an observation that no-one seemed to 
be able to agree on the role of the sKID, with all manner of possible 
interpretations having been presented in the recent thread.  Seeing everyone 
trying to figure out how to interpret the sKID requirements reminded me of 
people trying to read tea leaves.

Getting somewhat more tongue-in-cheek now:

>I'm sure that some customers have created PKIs where name chaining doesn't 
>hold, 

Standard practice for cross-certification, re-parenting, and all the other 
stuff that I gave the generic label "spaghetti PKI" to (you can tell from the 
label I use for it what I think of it :-).

>but that's an error on the customer's part.

That's what I've been saying for years (see e.g. my statement a couple of months
back "There is a special name for a PKI of this kind.  It's called 'Broken' or
'Defective'"), but I guess that's something the spaghetti PKI fans and myself 
will have to agree to disagree on.

>In fact, they may have opened themselves and their customers up to security 
>holes and perhaps even legal liability.

When was anyone ever held liable for implementing a broken PKI?  Usually any 
investment of large amounts of money that results in a broken PKI is followed 
by the investment of even more money in it (either that or the quiet 
cancellation of the project).  No-one ever gets held liable.  Why do you think
we have products like the ones you mentioned out there?

>This reminds me of Microsoft's decision to not check the Basic Constraints 
>extension, treating every certificate as a CA certificate. This decision, 
>presumably made in to please a customer, resulted in a HUGE security hole.

It wasn't a conscious decision, just bad programming.  Mozilla (and no doubt 
some others that didn't get any publicity) did the same thing, and I'm sure 
they didn't get asked to do that by customers.  The flaw had been known for at 
least five years, but no-one cared until the scaremongering in the media forced 
vendors to fix things (see the above comments about liability - you can get 
away with calling anything you like "X.509 standards-compliant", so why bother 
doing the job properly?).

Peter.