Subject: RE: On cross-certificates and pathLenConstraint

From: "Peter Hesse" <[email-masked]>
Date: Wed, 1 Sep 2004 15:05:51 -0400

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 14:15:53 -0400

Stefan and Steve Hanna:

   required to implement this algorithm, but MUST provide functionality

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

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
 
for
limit
>     the set of valid certification paths which begin with a particular
during
presence
certificate,
>     or the application MAY impose requirements on application-specific
section
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 
> validation implementations will do this. If they REALLY want to ensure 
> that path lengths are limited, they should certify a subsidiary CA and 
> Now, there's a separate question about whether processing constraints 
> > certification path values permitted by 3280, but for values such as
path
to
> >>If I am getting you right, you are saying that the exensions in the 
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 
> > 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 
> > BTW, Santosh is correct in noting that TAs are not literally certs, 
> > appear in a CA cert, and to then use them (most of them?) to control 
> > path processing.
> >
> > Steve
> >