Subject: RE: Cross certificate format

From: Sharon Boeyen <[email-masked]>
Date: Thu, 6 May 2004 11:34:16 -0400

I'd also like to clarify that the constraints that input to the path
validation process (e.g. initial-policy-mapping-inhibit,
initial-explicit-policy etc) are not tied necessarily to the trust anchor
but are tied to an instance of path validation conducted by the relying
party. It may be the relying party and not CA who happens to be the trust
anchor that determines these constraints. They are just additional inputs to
the process, as is the trust anchor public key. The same validation engine
may have different constraints on instances of path validation that use the
same trust anchor public key. Also, the same set of constraints can apply to
instances of validation that use different trust anchors. Different users,
different apps and even different transactions can have different
constraints even though they may happen to use the same trust anchor. While
it is true that including some extensions in a self-signed might be one way
to convey constraints that could then be extracted and provided as the
relevant inputs to the validation process, this is certainly not the only
way to convey initialization constraint values for a RP. Also, I believe it
is a very limiting way because then the constraints are tied to all
validations that occur with that key by all RPs (assuming all RPs used that
scheme to initialize their path validation variables). The mechanisms that
determine those inputs to the path validation process (including which trust
anchor public key to use, process are outside the scope of X.509. X.509
provides the mechanism (path validation variable initialization) to set the
constraints once the RP has determined what they are to be. 

On the nameConstraints issue, there is work underway in X.509 that will add
one more input to the path validation process to enable nameConstraints to
be imposed at initialization time just as other constraints can already.
Similar to the other constraints, no single value of initialization
constraints is tied necessarily to all uses of a trust anchor public key.  

On the earlier discussion of processing extensions in self-signed certs. I
believe X.509 and 3280 are completely consistent here in pointing out that
the self-signed cert is not part of the path (but may be a convenient way
for a CA to convey its public key). See clause 8.1.5 of X.509 for the
relevant text "For purposes of path validation, self-issued certificates of
type a) are verified with the public key contained in them, and if they are
encountered in the path, they shall be ignored." As a result of Defect
Report 285, that same point is the basic certificate checks in the path
processing alogithm in X.509. In the first paragraph of 10.5.1, you'll find
the sentence "Self-signed certificates, if encountered in the path are
ignored."

As for the checking of whether a self-signed cert has basic constraints with
CA set to TRUE etc, that is part of the checking that could be done to place
trust in the fact that certified key should be used as an input to the path
validation process. However, because X.509 does not mandate any scheme for
conveying these keys to users, it obviously doesn't mandate any checks on
those schemes. Any checking along these lines is outside the scope of the
path validation process because it would be done before the process is
initialized with that key.

Sorry for the lengthy message
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Steve Hanna
Sent: Wednesday, May 05, 2004 5:26 PM
To: Tom Gindin
Cc: Santosh Chokhani; [email-masked]
Subject: Re: Cross certificate format

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

Tom Gindin wrote:
>         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.
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>