Subject: RE: On cross-certificates and pathLenConstraint

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 2 Sep 2004 01:39:38 +0100

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. 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).

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.

Note this mail is not a proposal to start working on 2). 

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Peter Hesse
> Sent: den 1 september 2004 21:06
> To: 'Santosh Chokhani'; Stefan Santesson; 'Steve Hanna'
> Cc: [email-masked]
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> I agree wholeheartedly with Santosh.  Interoperability is what will be
> adversely affected if people use trust anchors to initialize path
> processing
> in different ways.  We should have a standard which clearly defines
how
> this
> mechanism should take place.
> 
> IMHO, CA vendors should be able to produce a self-signed certificate
with
> no
> (or few) extensions for basic interoperability, and one or more
additional
> self-signed certificates containing initialization parameters for
> applications which can make use of them.  Likewise with certificate
> validation systems--they should be able to import a self-signed
> certificate
> as just a trust root (name and public key only) as well as an path
> validation initialization object (looking at things like initial name
> constraints).
> 
> --Peter
> 
> +---------------------------------------------------------------+
> | Peter Hesse                    [email-masked]     |
> | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> | ICQ: 1942828                     www.geminisecurity.com       |
> +---------------------------------------------------------------+
> "Pay no attention to what the critics say; there has never been
> a statue set up in honor of a critic." --Jean Sibelius
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> > Sent: Wednesday, September 01, 2004 2:16 PM
> > To: 'Stefan Santesson'; 'Steve Hanna'
> > Cc: [email-masked]
> > Subject: RE: On cross-certificates and pathLenConstraint
> >
> >
> > Stefan and Steve Hanna:
> >
> > Section 6.1 also states the following:
> >
> > "This section describes an algorithm for validating certification
> >    paths.  Conforming implementations of this specification are not
> >    required to implement this algorithm, but MUST provide
> > functionality
> >    equivalent to the external behavior resulting from this
procedure.
> >    Any algorithm may be used by a particular implementation so long
as
> >    it derives the correct result."
> >
> > While I agree that we could take the values from trust anchor
> > to initialize the certification path validation, that is not
> > what the standard permits.
> >
> > As to your statement on Section 6.2, the language you cite
> > and the examples imply items that either not integral to
> > certification path validation or are to process application
> > specific extensions.  The name constraints example is states
> > "apply name constraints to a specific trust anchor during
> >    the initialization phase".  This can mean is the trust
> > anchor appropriate for the name space.  Similarly, the
> > subject alt name in the end certificate is a pre or post path
> > validation example.
> >
> > I am also concerned about your interpretation since it has
> > negative implications for interoperability.
> >
> > Having said that, I am not averse to a change in the standard
> > that clearly defines what values can be initialized.
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stefan Santesson
> > Sent: Tuesday, August 31, 2004 7:52 PM
> > To: Steve Hanna; Santosh Chokhani
> > Cc: [email-masked]
> > Subject: RE: R: On cross-certificates and pathLenConstraint
> >
> >
> >
> > Thanks Steve for jumping in on this.
> >
> > We completely agree on the facts of RFC 3280 path processing
> > and I think you showed this very well with support from the
> > standard text.
> >
> > We happen to disagree on the good or bad with processing root
> > extensions but I think we should save that to later :-)
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Steve Hanna
> > > Sent: den 31 augusti 2004 22:05
> > > To: Santosh Chokhani
> > > Cc: [email-masked]
> > > Subject: Re: R: On cross-certificates and pathLenConstraint
> > >
> > >
> > > RFC 3280 says in section 6.1:
> > >
> > >     A particular certification path may not, however, be
appropriate
> > for
> > >     all applications.  Therefore, an application MAY augment this
> > >     algorithm to further limit the set of valid paths.
> > >
> > > and in section 6.2:
> > >
> > >     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.
> > >
> > > Therefore, I believe that path validation implementations can go
> > > beyond the usual path validation algorithm to impose any
additional
> > > requirements on paths that it likes (unless specifically
> > prohibited by
> > > RFC 3280). This would include processing name constraints in trust
> > > anchors, pathLenConstraints in trust anchors, etc.
> > >
> > > However, CAs who expect to act as trust anchors and issue
> > self-signed
> > > certificates for that purpose should not assume that all path
> > > validation implementations will do this. If they REALLY
> > want to ensure
> > > that path lengths are limited, they should certify a
> > subsidiary CA and
> > > include a pathLen constraint in that certificate.
> > >
> > > Now, there's a separate question about whether processing
> > constraints
> > > in trust anchors is a good idea. I would argue that it's not. But
> > > that's a topic for another email.
> > >
> > > Thanks,
> > >
> > > Steve
> > >
> > > Santosh Chokhani wrote:
> > >
> > > > Steve Kent:
> > > >
> > > > We could take extensions in the TA and use them to initialize a
> > > > certification path values permitted by 3280, but for
> > values such as
> > path
> > > > length that 3280 does not permit initialization of to an
arbitrary
> > > value, it
> > > > will require a change in the standard.
> > > >
> > > > From security viewpoint, I do not object to it, but it is a
change
> > to
> > > the
> > > > standard.
> > > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On
> > > > Behalf Of Stephen Kent
> > > > Sent: Tuesday, August 31, 2004 9:51 AM
> > > > To: Santoni Adriano
> > > > Cc: [email-masked]
> > > > Subject: Re: R: On cross-certificates and pathLenConstraint
> > > >
> > > >
> > > >
> > > > At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> > > >
> > > >>If I am getting you right, you are saying that the
> > exensions in the
> > > >>self-signed certificate of a trust anchor (root CA) should be
> > > >>ignored. This is quite suprising to me!
> > > >
> > > >
> > > > Unfortunately that is what X.509 has said for some time, and
3280
> > has
> > > > not deviated in this regard. I too was surprised by this
> > initially.
> > > >
> > > > I discussed this issue with Sharon some time ago, noting
> > that, for
> > > > example, one would like to impose name constraints through
> > > > configuration of trust anchors and the TA exception to
> > the general
> > > > processing rules prohibits that.  So I agree completely
> > that I would
> > > > like to see at least SOME of the constraints in a trust
> > anchor cert
> > > > be applied to cert path processing, although one needs to
> > carefully
> > > > examine the implications of doing this.
> > > >
> > > > BTW, Santosh is correct in noting that TAs are not
> > literally certs,
> > > > even though self-signed certs are often used as a means of
> > > > representing TAs. However, since we admit that a TA can contain
> > > > parameters other than the TA name and key info, I think it is
> > > > reasonable to allow for the full range of extensions that might
> > > > appear in a CA cert, and to then use them (most of them?)
> > to control
> > > > path processing.
> > > >
> > > > Steve
> > > >
> >
> >

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 1 Sep 2004 22:48:22 -0400

Stefan:

I am ok with it as long as long as if a product or toolkit or API that
claims 3280 compliance, provides an interface to the path validation engine
to test compliance with 3280 and it passes the NIST PKITS tests.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 01, 2004 8:40 PM
To: Peter Hesse; Santosh Chokhani; Steve Hanna
Cc: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

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. 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).

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.

/Stefan

> processing in different ways.  We should have a standard which clearly 
> defines
how
with
additional
> certificate as just a trust root (name and public key only) as well as 
> an path validation initialization object (looking at things like 
> initial name constraints).
> 
> --Peter
> 
> "Pay no attention to what the critics say; there has never been a 
> statue set up in honor of a critic." --Jean Sibelius
> 
> 
procedure.
as
> > While I agree that we could take the values from trust anchor to 
> > initialize the certification path validation, that is not what the 
> > standard permits.
> >
> > As to your statement on Section 6.2, the language you cite and the 
> > examples imply items that either not integral to certification path 
> > validation or are to process application specific extensions.  The 
> > name constraints example is states "apply name constraints to a 
> > specific trust anchor during
> >    the initialization phase".  This can mean is the trust anchor 
> > appropriate for the name space.  Similarly, the subject alt name in 
> > the end certificate is a pre or post path validation example.
> >
> > I am also concerned about your interpretation since it has negative 
> > implications for interoperability.
> >
> > Having said that, I am not averse to a change in the standard that 
> > clearly defines what values can be initialized.
> >
> > We completely agree on the facts of RFC 3280 path processing and I 
> > think you showed this very well with support from the standard text.
> >
appropriate
additional
arbitrary
change
3280