Subject: RE: 3280 Bis: Initial Values for Permitted and Excluded Subtrees

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 15 Sep 2006 18:55:24 -0700

David,

I would request that we do that, i.e., make it explicit in
initialization.

Thanks.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: Friday, September 15, 2006 5:51 PM
To: pkix
Subject: Re: 3280 Bis: Initial Values for Permitted and Excluded
Subtrees

Russ Housley wrote: 

I have been thinking about this, and I think it would be a very good
idea to add these.  The algorithm in section 6 already has state
variables for permitted and excluded subtrees.  This is a minor change
to permit them to be initialized to algorithm input values.

3280bis already permits setting initial values for name constraints,
just not in section 6.1.  The following text appears in section 6.2
(Using the Path Validation Algorithm) and is basically unchanged from
RFC 3280:

         An implementation MAY augment the algorithm presented in
section 6.1
         to further limit the set of valid certification paths that
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, ....

Of course, 3280bis could formally add the initialization of permitted
and excluded subtrees to the path validation algorithm by adding it to
section 6.1.  Since RFC 3280 and 3280bis already permit this it wouldn't
really be a change, it would just make the option more visible.  So, I
would have no objection to moving this option to section 6.1.

Dave

At 07:00 PM 8/24/2006, Santosh Chokhani wrote:

All,
 
The new version of X.509 (2005 Edition) permits initial values other
than infinity and null for permitted and excluded subtrees respectively.
 
Should we also revise 3280Bis to include these options so that the
relying parties can constrain the trust anchors?
 
I would consider infinity and null values only for the two respective
fields still compliant with the applicable standard.
 
Thanks in advance for your opinion.

Santosh Chokhani 
Orion Security Solutions, Inc. 
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101 
(703) 917-0060 Ext. 35 (voice) 
(703) 917-0260 (Fax) 
[email-masked] 
Visit our Web site 
http://www.orionsec.com

---

From: Tom Gindin <[email-masked]>
Date: Sat, 16 Sep 2006 17:57:23 -0400

I'm for this too.  Does including max_path_length make sense as 
well?  I believe that it does.  Setting it to 0, in particular, trusts a 
CA to issue end-entity certificates without trusting it to issue cross 
certificates.

                Tom Gindin

"Santosh Chokhani" <[email-masked]> 
Sent by: [email-masked]
09/15/2006 09:55 PM

To
"David A. Cooper" <[email-masked]>, "pkix" <[email-masked]>
cc

Subject
RE: 3280 Bis: Initial Values for Permitted and Excluded Subtrees

David,
 
I would request that we do that, i.e., make it explicit in initialization.
 
Thanks.

From: [email-masked] [mailto:[email-masked]] 
On Behalf Of David A. Cooper
Sent: Friday, September 15, 2006 5:51 PM
To: pkix
Subject: Re: 3280 Bis: Initial Values for Permitted and Excluded Subtrees
 
Russ Housley wrote: 
I have been thinking about this, and I think it would be a very good idea 
to add these.  The algorithm in section 6 already has state variables for 
permitted and excluded subtrees.  This is a minor change to permit them to 
be initialized to algorithm input values.
3280bis already permits setting initial values for name constraints, just 
not in section 6.1.  The following text appears in section 6.2 (Using the 
Path Validation Algorithm) and is basically unchanged from RFC 3280:

         An implementation MAY augment the algorithm presented in section 
6.1
         to further limit the set of valid certification paths that 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, ....

Of course, 3280bis could formally add the initialization of permitted and 
excluded subtrees to the path validation algorithm by adding it to section 
6.1.  Since RFC 3280 and 3280bis already permit this it wouldn't really be 
a change, it would just make the option more visible.  So, I would have no 
objection to moving this option to section 6.1.

Dave

All,
 
The new version of X.509 (2005 Edition) permits initial values other than 
infinity and null for permitted and excluded subtrees respectively.
 
Should we also revise 3280Bis to include these options so that the relying 
parties can constrain the trust anchors?

Santosh Chokhani