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

From: Russ Housley <[email-masked]>
Date: Fri, 15 Sep 2006 16:11:36 -0400

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.

Russ

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: "David A. Cooper" <[email-masked]>
Date: Fri, 15 Sep 2006 17:50:36 -0400

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.

Santosh Chokhani

McLean, Virginia 22101

(703) 917-0060
Ext. 35
(voice)

(703) 917-0260 (Fax)

[email-masked]

Visit our Web site

http://www.orionsec.com

---

From: Russ Housley <[email-masked]>
Date: Sat, 16 Sep 2006 12:26:25 -0400

David:

You are correct.  I just think it is worth the two paragraphs to
make the inputs more visible.  I guess we would also need to change
the "for example" on section 6.1.

Russ

At 05:50 PM 9/15/2006, David A. Cooper wrote:

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,

Santosh Chokhani

McLean, Virginia 22101

(703) 917-0060
Ext. 35 (voice)

(703) 917-0260 (Fax)

[email-masked]

Visit our Web site

http://www.orionsec.com

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 18 Sep 2006 11:27:47 +0200

Doesn't the MAY in the sentence permit an implementation to be conformant
if it does not provide the possibility?  This deosn't seem to be the 
same in X.509 where
the possibility of adding the constraints is part of the input of the 
path validation algorithm.

The inputs to the certification path processing procedure are:
...

h) an initial-permitted-subtrees-set containing an initial set of 
subtree specifications defining subtrees within which subject names (of 
the name form used to specify the subtrees) are permitted. In the 
certificates in the certification path all subject names of a given name 
form, for which initial permitted subtrees are defined, shall fall 
within the permitted subtrees set for that given name form. This input 
may also contain the special value unbounded to indicate that initially 
all subject names are acceptable. For clause 10, subject names are those 
name values appearing in the subject field or the subjectAltName extension;

David A. Cooper wrote:
> 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 
>> change to permit them to be initialized to algorithm input values.
>          a particular trust anchor.  For example, an implementation 
> MAY modify
>>> than infinity and null for permitted and excluded subtrees respectively.
>>>  
>>> I would consider infinity and null values only for the two 
>>> respective fields still compliant with the applicable standard.
>>>  
>>> (703) 917-0060 Ext. 35 (voice)
>>> (703) 917-0260 (Fax)
>>> [email-masked] <mailto:[email-masked]>
>>> Visit our Web site
>>> http://www.orionsec.com
>>>   
>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.