Subject: Re: Love's issue #4; was: Re: PKINIT open issues

From: Martin Rex <[email-masked]>
Date: Thu, 10 Jun 2004 00:16:09 +0200 (MET DST)

Jeffrey Altman wrote:
> 
> Martin Rex wrote:
> 
> >Well, that explanation is all what TLS did about the ambiguity of SSLv3.
> >I forgot to mention the actual problems that come with this.
> >
> >If the certificate chain includes the RootCA certificate:
> > - may it be completely ignored by the receipient
> >  
>
> It may be completely ignored by the recipient.  The only benefit that 
> including the RootCA certificate does is allow the client application
> to display the certificate to the end user to determine whether or not
> it should be trusted (assuming it passes all of the other validation
> tests). 

I fully agree about the mentioned purpose of sending a RootCA cert.
However what should one do about RootCA certificates included in the
forward certification path that will fail validation, e.g. when they're
expired/not yet valid or worse: when the signature verification fails?

There are only two reasonable choices:

1) the optional RootCA cert may be verified, however all errors MUST be ignored

2) the optional RootCA cert MUST be verified if present and the whole
    communication MUST fail if the verification fails

everything else will cause interoperability problems and lots of headaches.

But since those mutually exclusive, the spec has to explicitly specify
either one.

> 
> The RootCA certificate when included in the chain must match exactly the 
> certificate stored in the Trusted CA database.  If it does not,
> the RootCA certificate MUST NOT be trusted.

That's a given.  Trust is always strictly limited to (pre-)configured
trust (anchors), and certificates sent by peers are only considered valid
if they can be verified by chaining or matching to one of the existing trust
anchors.

> 
> > - should it be completely verified by the recipient
> >   (e.g. self-signature, Key usage, Validity period and validity
> >         period chaining, policies, etc.)
> >
> >  
> >
> Absolutely.  If the self-signed certificate is not valid it should be 
> dropped on the floor like a hot potato.  This is true for Intermediate
> CA certificates as well.  The only difference between Intermediate CA
> certs is that they MUST be included in the chain. 

What do you mean by "dropped on the floor" here?
What consequences MUST a verification failure have on the entire
authentication process (and any related communication)?

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 09 Jun 2004 18:24:36 -0400

>authentication process (and any related communication)?
The verification of the the chain fails.  The authentication process 
fails.  The user cannot
obtain Kerberos tickets.

Jeffrey Altman

---

From: "D. R. Evans" <[email-masked]>
Date: Thu, 10 Jun 2004 12:52:40 -0600

Jeffrey Altman said the following at 06/09/2004 04:24 PM:-
> The verification of the the chain fails.  The authentication process 

Absolutely. Anything else sounds like a death wish :-)

   Doc

-- 

-----------------------------------------------------------
Office: +1 303 494 0394
Mobile: +1 720 839 8462
Fax:    +1 781 240 0527
-----------------------------------------------------------

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Jun 2004 15:13:09 -0400

Do we really have to specify certificate verification?  ISn't that a
CMS problem?  Or to the extent that we do have to profile aspects of
it is it clearly specified what we must profile?