Re: Request change in son-of-rfc2633

[Steve Hanna <[e-mail]>]

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.

In section 6.1:

 To meet this goal, the path validation process verifies, among other
 things, that a prospective certification path (a sequence of n
 certificates) satisfies the following conditions:

    (a)  for all x in {1, ..., n-1}, the subject of certificate x is
    the issuer of certificate x+1;

In section 6.1.3:

 (a)  Verify the basic certificate information.  The certificate
 MUST satisfy each of the following:

 [...]

    (4)  The certificate issuer name is the working_issuer_name.

In section 4.1.2.6:

   If the subject is a CA (e.g., the basic constraints extension, as
   discussed in 4.2.1.10, is present and the value of cA is TRUE), then
   the subject field MUST be populated with a non-empty distinguished
   name matching the contents of the issuer field (section 4.1.2.4) in
   all certificates issued by the subject CA.

RFC 2459 and X.509 both agree with this.

Whatever PKI topology you use, there's no need to break
name chaining. I'm sure that some customers have created
PKIs where name chaining doesn't hold, but that's an error
on the customer's part. You can't just turn off critical
security checks to keep them happy. What's next? Don't
bother checking the signature on certificates. That takes
too much time!

If somebody has implemented path validation without name
chaining checks, then they haven't implemented it according
to IETF or X.509 standards. In fact, they may have opened
themselves and their customers up to security holes and
perhaps even legal liability. CAs have every right to expect
that certificates will be validated according to standards.
Users also have a reasonable expectation of this. If someone
deliberately violates the standards in a way that opens
up security holes, that sounds like gross negligence to me.

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.

I hope that Microsoft (and anyone else who has skipped
required parts of the path validation algorithm for the
sake of convenience) will see that security cannot be
second to user convenience. If there's a serious problem
with the specs, then let's fix them. But don't just bypass
things because you find it convenient.

Forgive me my rant. I'm just outraged that somebody would
play fast and loose with security this way.

Thanks,

Steve

Peter Gutmann wrote:
> 
> [Cross-posted back to S/MIME, where the thread started]
> 
> Eric Norman <[e-mail]> writes:
> 
> >Is there a claim (#1 above) that you can have the DN in the subject of a
> >parent's (signer's) certificate be different from (as in different bunch of
> >bytes) the DN in the issuer of one of its offspring and yet the chain is
> >still valid because the xKIDs match?
> 
> Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI that
> violates the original X.509 design, i.e. with re-parenting, arbitrary cross-
> certification, etc etc where issuers no longer match subjects).  For example
> MS apparently implemented chaining by sKID in Windows because of user demand
> for this when the users broke chaining by issuer name through spaghetti PKI
> design practices, and various other implementations no doubt do similar
> things, depending on how they've read the PKIX tea leaves.
> 
> Peter.