Subject: RE: Cross certificate format

From: Tom Gindin <[email-masked]>
Date: Tue, 4 May 2004 23:39:26 -0400

Santosh:

        Of course, defining a trust anchor implies that the RP trusts the 
anchor's public key as an issuer for at least some purposes.  RFC 3280, in 
the parts of section 6.1.2 I cited, appears to forbid those state 
variables from being set from information defined by the RP or stored with 
the trust anchor.  This is consistent with its statements in 6.1.1 d which 
permit self-signed certificates but say nothing about other CA 
certificates.  As is probably clear to everyone reading this thread, I 
think that this is not an ideal set of suggestions.
        The current standard does contain some constraints on the trust 
anchor (notably inhibit-policy-mapping), but neither name constraints nor 
basic constraints.  I consider this an anomaly.  If I had free rein in 
rewording pieces of RFC 3280 section 6.1, I would change this wording to 
allow CA certificates along with self-signed ones as anchors and create 
extra optional (and optional to support) fields to be set from the trust 
anchor.
        I don't think that this is particularly inconsistent with general 
security principles, or with any part of X.509 with which I am familiar. 
It does represent an extension of RFC 3280 section 6, and it is only 
backward compatible with it, so it may be out of scope.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
05/01/2004 06:46 PM

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

Tom:

The standard does not require you to check how you initialize the 
variables.
You can get these from the cross certificate or from some configuration.

The basic point is that you trust the public key.  How you constrain it is
not address by the standard, where as if the same certificate appeared in 
a
path, you have to apply the constraints or be not compliant with the
standard.

You obviously do not believe in re-incarnation.  Just kidding......

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Saturday, May 01, 2004 6:31 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Cross certificate format

        Santosh:

        It is well known that trust in a trust anchor can be defined in a 
variety of ways.  However, there is every reason to think that an RP may 
constrain that trust and that the constraints he may apply include those 
which an issuer CA may apply to a subordinate one. The wording of RFC 3280 

section 6.2's first paragraph is an example of this.
        My comments about the meaning of a trust anchor are not purely 
theoretical.  If a cross certificate is used to represent a trust anchor, 
the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
(RFC 3280 6.1.2 c) could easily be set from the contents of a 
NameConstraints extension, and the variable max_path_length (RFC 3280 
6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
today, these variables are set to constants (although that interpretation 
is not absolutely clear for permitted_subtrees).  In fact, they are three 
of the four variables which are set to constants during initialization.
        If permitted subtrees were set to a list of attributes, the 
validation process would fail if the anchor CA or a CA it certified went 
beyond the restrictions of those attributes.  Likewise, if the excluded 
subtrees were set to a list of attributes, the validation process would 
fail if the anchor CA or a CA it certified went used values matching any 
of those attributes.  I do not believe that I am arguing against Galileo.

                Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
04/29/2004 11:12 PM

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

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:

        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: Wed, 5 May 2004 13:26:15 -0400

Tom:

I think we agree on what the standards currently do not require any checks.

X.509 is being revised (since I do not keep track of the process -- X.509
change may have been approved for all know) to permit the relying party to
specify these values.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Tuesday, May 04, 2004 11:39 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: Cross certificate format

        Santosh:

                Tom Gindin

        To:     <[email-masked]>
        cc: 

Tom:

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Saturday, May 01, 2004 6:31 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-----

        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:

---

From: Steve Hanna <[email-masked]>
Date: Wed, 05 May 2004 17:26:00 -0400

See section 6.2 of RFC 3280, which says:

    ...  An implementation that supports multiple trust anchors
    MAY augment the algorithm presented in section 6.1 to further limit
    the set of valid certification paths which begin with a particular
    trust anchor.  For example, an implementation MAY modify the
    algorithm to apply name constraints to a specific trust anchor during
    the initialization phase, or the application MAY require the presence
    of a particular alternative name form in the end entity certificate,
    or the application MAY impose requirements on application-specific
    extensions.  Thus, the path validation algorithm presented in section
    6.1 defines the minimum conditions for a path to be considered valid.

There's no need to change RFC 3280 to allow
path validation implementations to apply
name constraints to trust anchors. That's
explicitly discussed in this section of the RFC.

Thanks,

Steve