Subject: RE: On cross-certificates and pathLenConstraint

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 3 Sep 2004 09:04:47 +0100

Santosh,

That is not at all what I try to say.

First of all. If you have the ability to augment the standard algorithm,
does not mean that you necessarily don't have a default mode that you
can use for standard compliance testing.

Secondly, even if you run in some augmented mode, you can still make
tests to make sure that a bad path, actually is rejected (i.e. no valid
augmentation allows a bad path to pass). Even in this mode you can make
many valid standards compliance claims.

Finally you are right about the tricky part to test compliance and
interop regarding variable initialization. This is because the algorithm
specified in RFC 3280 is one example of a compliant algorithm, and even
if it were THE algorithm, different implementations of it would still
have different APIs with different ways and methods to handle these
variables. 

Example. 
Implementation 1 has a certain way to initialize a variable in the API
request and delivers a distinct result.

Implementation 2 does not provide any possibility to initialize this
variable but does instead deliver a response that can be masked for the
proper mode of operation (=different variable settings).

As long as we don't standardize the APIs we will have hard time making
these tests effectively.

I agree that it is a bit confusing that RFC 3280 define the ability to
initialize some variables while it at the same time has a language that
opens for adding any other type of constraints to the process.

So I do believe that the only thing you can successfully test widely is
the default algorithm with default parameter settings, which is exactly
what NIST PKITS is doing.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 3 september 2004 01:14
> To: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 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.
> >
> >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: "Santosh Chokhani" <[email-masked]>
Date: Fri, 3 Sep 2004 08:50:13 -0400

Stefan:

I would note two things.  They seem to be repeat of the themes from me in
this thread.

1.  For interoperability reasons, it is not sufficient to reject paths
considered bad by 3280.  Paths considered good by 3280 should also be
accepted.

2.  The key is the RP user to be able to set the path validation engine
initialization variables as opposed to the engine/API making that
determination for the entire consumer/RP community. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Friday, September 03, 2004 4:05 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Santosh,

First of all. If you have the ability to augment the standard algorithm,
does not mean that you necessarily don't have a default mode that you can
use for standard compliance testing.

Secondly, even if you run in some augmented mode, you can still make tests
to make sure that a bad path, actually is rejected (i.e. no valid
augmentation allows a bad path to pass). Even in this mode you can make many
valid standards compliance claims.

Finally you are right about the tricky part to test compliance and interop
regarding variable initialization. This is because the algorithm specified
in RFC 3280 is one example of a compliant algorithm, and even if it were THE
algorithm, different implementations of it would still have different APIs
with different ways and methods to handle these variables. 

Example. 

As long as we don't standardize the APIs we will have hard time making these
tests effectively.

So I do believe that the only thing you can successfully test widely is the
default algorithm with default parameter settings, which is exactly what
NIST PKITS is doing.

/Stefan

engine's
as
claims.
TA
> name constraints. So, I think that an application is over stepping the 
> bounds of the standard if it initializes variables for which the 
longer
the
> under the standard path validation algorithm. So, if what you said was 
> that the USER could augment the path validation algorithm by 
> 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: Tom Gindin <[email-masked]>
Date: Mon, 6 Sep 2004 10:13:19 -0400

Santosh:

        If an algorithm accepts all paths which are recommended by RFC 
3280 section 6.1, in what sense could it be considered an "augmented" 
algorithm?  An augmented algorithm, in the natural sense of the term, does 
more processing than is done by the base algorithm.  If it is required to 
come to identical results in all cases, that extra processing is 
fruitless.
        For example, if an RP associates a permitted-subtree with a 
particular trust anchor in such a way that certificates whose subject DN 
contains a "C" attribute are not permitted to come from that anchor unless 
C's value matches the one in the anchor's DN, how does this violate RFC 
3280?  It directly follows a suggestion in RFC 3280 6.2.  I do not mean, 
of course, that that particular rule (no certification between anchors 
from one country and subjects from another) is one which any product 
should enforce unless the RP chooses it or the certificate the RP uses to 
represent an anchor contains it.
        What is required for interoperability is that when the RP does not 
choose any augmented conditions (either manually or by using a 
cross-certificate containing them) the software comes to the same results 
as RFC 3280.  The issue is not "does an RP decide to reject a certificate" 
but "may the RP place extra conditions on certificates he accepts through 
a given anchor, and reject those which fail"?
        In practice IMHO, many RP's will import anchor definitions from 
third parties with more expertise than the average user - corporate 
administrators, trusted agencies, or even software manufacturers. 
Constraints of the sort that I have been advocating could often come with 
the anchor definition.  Whether they are imported as part of a certificate 
or as separate fields (probably tagged as such in an XML or .ini format) 
is of secondary importance.
 
                Tom Gindin
P.S. -  The opinions in this posting are mine, and not necesarily those of 
my employer.

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
09/03/2004 08:50 AM
 
        To:     <[email-masked]>
        cc: 

Stefan:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On

Santosh,

many

in RFC 3280 is one example of a compliant algorithm, and even if it were 
THE

Example. 

these
tests effectively.

/Stefan

engine's
as
claims.
TA
longer
the

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 6 Sep 2004 14:13:20 -0400

Tom:

Are you really saying something different from what I am saying?

I am saying that;

1 If there is a capability to set the initialization variables beyond those
specified in the standard, the capability should be configurable; and

2.  When you set the values per standard, you should get the results per the
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Monday, September 06, 2004 10:13 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

        Santosh:

                Tom Gindin

        To:     <[email-masked]>
        cc: 

Stefan:

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

Santosh,

Example. 

/Stefan

engine's
as
claims.
TA
longer
the

---

From: Tom Gindin <[email-masked]>
Date: Wed, 8 Sep 2004 07:31:37 -0400

Santosh:

        I thought that you were also saying that setting such parameters 
was non-compliant with RFC 3280, or at least not interoperable with 
compliant implementations.  If you believe that setting such parameters is 
permissible and sometimes (not always) appropriate, then we certainly 
agree.
        On a separate point, my views on constraints in anchor definitions 
are different than Steve K.'s, but I don't think we're that far apart.  I 
don't think that it's any worse to have a vendor set a name constraint on 
a CA than for that same vendor to decide whether or not to include it in a 
default set of anchors in the first place.   I do believe that it is 
desirable for RP's to be able to edit anchor constraints (especially ones 
coming from the software vendor), just as it is for RP's to be able to add 
or delete anchor definitions.
        Lastly, IMHO an interchange format for anchor definitions should 
be defined, so that users can import those of other users (or corporate 
admins, or whoever they choose).  However, I doubt that it's this group's 
role to specify such a format.  If others think that it's in scope for 
PKIX, I won't complain.  Obviously, if such a format is supported for both 
export and import by most programs, and can be edited with standard tools, 
concerns about vendors over-controlling the RP's set of anchors would be 
greatly mitigated.

                Tom Gindin
P.S. -  The opinions in this posting are mine, and not necessarily those 
of my employer.

09/06/2004 02:13 PM
 
        To:     <[email-masked]>
        cc: 

Tom:

I am saying that;

1 If there is a capability to set the initialization variables beyond 
those
specified in the standard, the capability should be configurable; and

2.  When you set the values per standard, you should get the results per 
the
standard.

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

        Santosh:

 
                Tom Gindin

my employer.

        To:     <[email-masked]>
        cc: 

Stefan:

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

Santosh,

Example. 

/Stefan

engine's
as
claims.
TA
longer
the

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 8 Sep 2004 08:47:39 -0400

Tom:

See responses in-line in [].

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Wednesday, September 08, 2004 7:32 AM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

        Santosh:

[X.509 does not permit setting of some of the parameters today, but as
Sharon pointed out X.509 is in the revision process to permit setting these.
3280 should be interpreted as saying that the relying party can do some pre
or post processing, but there must be a path validation engine that complies
with the logic provided in Section 6.1.]

[My position is that it is desirable to use the constraints from the trust
anchor and then further constraint them.  (Of course, this is all change in
X.509 and 3280.)  For example if a trust anchor wants to constrain trust
emanating from it to a name space, the RP should honor that and can further
constrain the name space.  Same for path length.]

[I think this is in the scope of PKIX.  From practical viewpoint, due to
installed base, that format happens to be a certificate, self-signed or
otherwise.  So, I am not sure anything not accommodating certificates will
fly.]

                Tom Gindin

        To:     <[email-masked]>
        cc: 

Tom:

I am saying that;

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

        Santosh:

 
                Tom Gindin

my employer.

        To:     <[email-masked]>
        cc: 

Stefan:

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

Santosh,

Example. 

/Stefan

engine's
as
claims.
TA
longer
the

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Sep 2004 14:19:13 -0400

>or delete anchor definitions.

I am unhappy with vendors including default TAs in a product, so we 
are in agreement to some extent :-)

steve