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

From: Eric Norman <[email-masked]>
Date: Tue, 28 Oct 2003 00:18:52 -0600 (CST)

On Tue, 28 Oct 2003, Peter Gutmann wrote:

> As was almost everyone else.  The problem is that there are two incompatible
> interpretations of the sKID:
>
> 1. Alternative chaining mechanism if chaining by DN fails, e.g. with cert
>    reparenting or some types of spaghetti PKIs.
>
> 2. Disambiguating factor if chaining by DN leads to multiple issuers, e.g.
>    with other types of spaghetti PKIs.

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?  That doesn't seem like an
incompatible interpretation; it seems more like a totally unreasonable
(as in incorrect) interpretation.

Even if some issuer were changing its name but not its signing key, the
old certificates with the old name in the subject field would still be
used, wouldn't they?

Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 28 Oct 2003 11:51:26 +0100 (MET)

I always thought that the semantics of an SKID/AKID pair
(if keyidentifier is used) of just an AKID(choice issue/serial)
is the following:

During path building among all certificates that have the
chain correctly with the issuer/subject take all those
as candidates that have the same public key as the
one that is identified by the SKID/AKID. 

This is done in order to avoid unnecessary verification
of the certificate signature for all candidates.

Peter

---

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.

---

From: Tom Biskupic <[email-masked]>
Date: Thu, 30 Oct 2003 11:56:28 -0000

Oops my appologies the previous version of this message went out signed with
a test certificate.

Here is the text again.

Tom

> -----Original Message-----
> From: Tom Biskupic [mailto:[email-masked]]
> Sent: Thursday, 30 October 2003 17:29
> To: 'Santosh Chokhani'; [email-masked]
> Subject: RE: Request change in son-of-rfc2633
> 
> 
> Hello,
> 
> Umm What about if you managed to have a Sub-CA certified using the
> compromised key of another Sub CA?
> 
> The other sub CA was revoked (for key compromise) and 
> therefore all the
> certificates it issued are dead but if RP applications ignore the
> name-chaining, wouldn't this effectively re-activate those 
> certificates?
> RPs checking one of those dead certs (and ignoring name 
> chaining) could
> use the newly certified Sub CA to build a (well bogus) path and would
> accept that path.
> 
> Even POP won't save you as the entity applying to have the compromised
> CA key re-certified may have the private key (as it was compromised).
> 
> Some CAs will check that the same key is not issued to two 
> entities (and
> thus would refuse to re-certify the Sub CA with a different name)
> however do you want to rely on it?
> 
> Ok this is a bit theoretical... A Sub-CA being revoked for instance.
> 
> Tom
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Thursday, 30 October 2003 07:51
> > To: [email-masked]; [email-masked]
> > Subject: RE: Request change in son-of-rfc2633
> > 
> > 
> > Steve Hanna:
> > 
> > I agree with you that both 3280 and X.509 require name 
> > chaining.  However,
> > the security implications and security importance of name 
> chaining is
> > overstated.
> > 
> > For example, if signatures chain properly for the certificate 
> > and CRL and
> > the relying party has appropriate means (e.g., e-mail 
> > address) to identify
> > the subscriber, name chaining offers little in terms of security.
> > 
> > My statement should be read purely in security (and NOT 
> > interoperability)
> > context.
> > 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]
> > On Behalf Of Steve Hanna
> > Sent: Wednesday, October 29, 2003 9:58 AM
> > To: Peter Gutmann
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: Request change in son-of-rfc2633
> > 
> > 
> > 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 <[email-masked]> 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.
> > 
>