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

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 30 Oct 2003 11:10:12 -0500

Tom:

If the new Sub CA is rogue, name chaining will not help.  The CA who now
uses the compromise key can always issue certificates to those RP and assert
its own name.

If the new sub CA is not rogue and someone else compromised the original sub
CA key, that "someone else" can use the compromised key under the new CA
name to create bogus RPs.

If everything is benign, the original CA was revoked and not compromised,
some one could provide a certification path: root .....--> new CA --> RP
under old CA.  Without name chaining, this path could be validated and thus,
if the RP was compromised, that compromise can be exploited.  But, this is
only if the two CAs benignly use the same key. 

-----Original Message-----
From: Tom Biskupic [mailto:[email-masked]] 
Sent: Thursday, October 30, 2003 1:29 AM
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.
>

---

From: jim <[email-masked]>
Date: Thu, 30 Oct 2003 20:02:32 -0500

After the KEYJACKING paper that was presented at the last PKI 
Development Conference, I am not clear on the push for using SMIME since 
we know that any transactions using SSL or VPN technologies subject the 
key to being compromised.  Is there some new technology that I am not 
familiar with and has that been reviewed by the team from Dartmouth that 
presented the paper to see if it was truly better?

Jim Heimberg, ABC, Ph.D.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 30 Oct 2003 18:36:40 -0800

At 8:02 PM -0500 10/30/03, jim wrote:
>Development Conference, I am not clear on the push for using SMIME 
>since we know that any transactions using SSL or VPN technologies 
>subject the key to being compromised.

The paper talks about scenarios that compromise the entire PC, not 
just S/MIME. So you are saying "if the user can use client-side 
certs, you cannot trust anything on the PC ever again". That may be 
true, but it is irrelevant to the discussion of S/MIME and probably 
to PKIX as well.

PCs are vulnerable. This doesn't mean we stop all development of 
things that run on PCs.

(FWIW, the paper can be found at 
<http://www.cs.dartmouth.edu/~sws/papers/keyjack.pdf>.)

--Paul Hoffman, Director
--Internet Mail Consortium