Subject: RE: On cross-certificates and pathLenConstraint

From: Stephen Kent <[email-masked]>
Date: Thu, 2 Sep 2004 16:17:41 -0400

At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
>Applying local trust policies is not a matter of interoperability. It is
>just a matter of local policy.
>
>An application may be configured, in accordance with local policy to
>reject a certificate based on any reason it chooses.
>
>We are not arguing about how RFC 3280 path validation works. RFC 3280
>path validation ignores TA extensions. Period.
>
>But if an application chooses to accept any restrictions set in the TA
>certificate, it is entitled to do so at its own discretion.

I was in agreement up to this point. The path validation process 
divides has fixed aspects, and a user-settable aspects. In terms of 
initialization, the standards (X.509 and RFC 3280) don't provide a 
means to initialize some of the variables that we would like, e.g., 
name constraints. So, I think that an application is over stepping 
the bounds of the standard if it initializes variables for which the 
standards make no such provision.

>It is not up
>to any standard to say that it can't. This is then of course no longer
>basic RFC 3280 validation, but some form of augmented RFC 3280 path
>validation (I.e RFC 3280 path validation + some locally defined
>additional constraints).

i.e., it's non-standard :-)

>The only interoperability issue at hand is to make sure that all
>applications 1) who choose just basic RFC 3280 path validation use the
>same rules and optionally 2) that those who choose to honour TA
>extensions may do so in a uniform manner thanks to clearly defined
>rules.

well, I'm generally opposed to having a CA issue a self-signed cert 
that is used as a TA, given that the TA parameters should be 
controlled by an RP, not the CA. BUT, the reality is that many folks 
DO take such certs and use them as TAs, then the problem with your 
suggestion is that the same cert use as a TA by different RPs will 
have different effects, which is not what the CA would anticipate 
under the standard path validation algorithm. So, if what you said 
was that the USER could augment the path validation algorithm by 
initializing parameter values that the standards don't allow, I'd be 
sympathetic since the intent is to allow the user, as an RP, to do 
what he should be able to do. But, you refer to an application doing 
this, not a user, and for that I am less sympathetic, because it 
sounds like a vendor of an application making a decision for 
everyone, and that is not in the spirit of allowing the RPs to 
exercise control over the validation process.

So, which do you mean?

Steve

---

From: David Engberg <[email-masked]>
Date: Thu, 02 Sep 2004 19:05:35 -0400

Steve -

Would you mind expanding on this thought a little?:

> Well, I'm generally opposed to having a CA issue a self-signed cert
> controlled by an RP, not the CA.

 From a security standpoint, I can see how a Trust Anchor is really just 
a Distinguished Name plus a public key.  A self-signed cert seems like a 
harmless way to package these two into a single file.

Some of the other fields in the self-signed cert file may even serve as 
metadata annotations (e.g. validity.notAfter) which may be useful to an 
RP.  Obviously, any adoption of these additional fields into the RP's 
local policy is outside the bounds of RFC 3280.

Do you have a preferred alternate representation for disseminating TA 
information without using self-signed certs?

Thanks

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 2 Sep 2004 19:13:58 -0400

Stefan:

An advantage of what Steve Kent is saying is that the validation engine's
compliance to 3280 can be conformance tested for the current standard as
well as for revised standard that contained features for the RP to
initialize the various state variables.

If you use your argument, we can not make any standard compliance claims.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Thursday, September 02, 2004 4:18 PM
To: Stefan Santesson
Cc: Peter Hesse; Santosh Chokhani; Steve Hanna; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

At 1:39 AM +0100 9/2/04, Stefan Santesson wrote:
>Applying local trust policies is not a matter of interoperability. It 
>is just a matter of local policy.
>

So, which do you mean?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 3 Sep 2004 10:30:39 -0400

At 7:05 PM -0400 9/2/04, David Engberg wrote:
>From a security standpoint, I can see how a Trust Anchor is really 
>just a Distinguished Name plus a public key.  A self-signed cert 
>seems like a harmless way to package these two into a single file.

harmless, yes, but also functionally limiting to whatever extent we 
use extensions from the TA to influence path validation.

>Some of the other fields in the self-signed cert file may even serve 
>as metadata annotations (e.g. validity.notAfter) which may be useful 
>to an RP.  Obviously, any adoption of these additional fields into 
>the RP's local policy is outside the bounds of RFC 3280.

which creates uncertainly for users on terms of what their software 
really does, if they rely on it to give a yea/nay decision re use of 
a cert. that's not a good situation.

>Do you have a preferred alternate representation for disseminating 
>TA information without using self-signed certs?

There are several "better" ways to represent TA info, some of which 
also help to disseminate it to end users. For example, in an 
enterprise context, the CA for the enterprise can act as the only TA 
for each user. It can issue cross certs to the other CAs that it 
wants to enable for path validation. The keys for these CAs may have 
been acquired from self-signed certs by the enterprise CA, but it can 
strip out the key and name and use only the parameters (extensions) 
from the self-signed cert that it wants, and it can insert other, 
appropriate extensions to effect appropriate path processing controls 
consistent with the enterprise policies.  This technique even avoids 
the need to change the specs to make use of extensions from TAs in 
path processing, since all of the cross certs that the enterprise CA 
issues are now processed as non-TAs.

An individual user can do the same thing, acting as his own, sole TA 
and issuing cross certs to all the CAs that he would have otherwise 
installed as TAs.

Steve