Subject: RE: Cross certificate format

From: Tom Gindin <[email-masked]>
Date: Thu, 29 Apr 2004 20:42:50 -0400

Santosh:

        I don't think that a CA certificate and a trust anchor are as much 
different things as different uses for the same thing.  They are both 
identifiers of issuers which bind a public key to an issuer name, and it 
is perfectly appropriate for any CA certificate to represent a trust 
anchor.  I also do not see why such things as name constraints on a trust 
anchor are inappropriate.  It is perfectly true that verifying a trust 
anchor's certificate, when issued by another CA (who may not be trusted) 
is a pointless operation.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/27/2004 09:14 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My point is that even if the trust anchor is a self-signed certificate, 
all
you need to do is extract the required information.  There is no need to
examine anything.

Cross certificate and trust anchor are very different things.  An element 
of
the cross certificate pair is nothing but an intermediate CA certificate 
in
a certification path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, April 27, 2004 7:33 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 

be provided as "a self-signed certificate", with no further qualification. 

 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/26/2004 08:51 AM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: Cross certificate format

Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [email-masked]
Subject: Re: Cross certificate format

        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 

it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 

by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 

with the KeyUsage extension present, it is only a valid issuer certificate 

if keyCertSign is set.

        Tom Gindin

Jean-Marc Desperrier <[email-masked]>
Sent by: [email-masked]
04/21/2004 03:42 PM

        To:     [email-masked]
        cc: 
        Subject:        Re: Cross certificate format

Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed
> certificates,

>which contain no extensions at all (see the text of RFC 3280's 
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 29 Apr 2004 23:12:15 -0400

Tom:

The basic point (at the risk of repeating myself) is that a CA certificate
or a self-signed certificate can be used as a means to provide trust anchor
information.  In that case, there is no need to check signature or anything.

But, when the CA certificate is a certificate in the certificate path, X.509
logic kicks in.

This is consistent with X.509, 3280 and general security principles since
the trust in a trust anchor can be derived through any number of means.

If you do not agree, feel free to argue against the definitions and Galileo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Thursday, April 29, 2004 8:43 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Cross certificate format

        Santosh:

                Tom Gindin

        To:     <[email-masked]>
        cc: 

Tom:

-----Original Message-----

        Santosh:

                Tom Gindin

        To:     <[email-masked]>
        cc: 

Tom:

-----Original Message-----

        Jean-Marc:

it is a trust anchor.

if keyCertSign is set.

        Tom Gindin

        To:     [email-masked]
        cc: