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

From: "David A. Cooper" <[email-masked]>
Date: Wed, 04 Oct 2006 15:03:48 -0400

While section 6.1.1 of RFC 3280 indicates that the path validation 
"algorithm assumes the following seven inputs are provided to the path 
processing logic", I do not believe that was intended to be a 
requirement to allow applications (or users) to set all of these 
values.  So, even if we add initial-permitted-subtrees and 
initial-excluded-subtrees to the set of inputs listed in section 6.1.1, 
I do not believe that this would require a conforming implementation to 
be able to validate paths using initial values for permitted_subtrees 
and excluded_subtrees other than "permit all" and "exclude none".  This 
would just be an example of an implementation that hard coded the values 
for the initial-permitted-subtrees and initial-excluded-subtrees inputs.

However, in order to avoid confusion, I propose adding a paragraph to 
the end of section 6.1.1 that explicitly states that conforming 
implementations may "hard code" the values for some of the inputs and 
are not required to be able to accept user/application supplied values 
for every input mentioned in the section.  Here is the text that I 
propose to add:

      Conforming implementations are not required to support the setting of
      all of these inputs.  For example, a conforming implementation may be
      designed to validate all certification paths using a value of FALSE
      for initial-any-policy-inhibit.

While I would have preferred to use initial-permitted-subtrees and 
initial-excluded-subtrees as the examples, since they are the two new 
inputs, I chose initial-any-policy-inhibit for the example since it is a 
simple boolean and thus much easier to describe.

Dave

Peter Sylvester wrote:
> 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 
>>> 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] <mailto:[email-masked]>
>>>> Visit our Web site
>>>> http://www.orionsec.com

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 10 Oct 2006 13:05:32 +0200

There is a current mismatch between x509 and 3280bis concerning the 
input of the path validation algorithm.
I think that the difference should be removed, i.e. the text from X509 
should be translated into
equivalent PKIX-speak (MUST, MAY, etc).

I think it is out of scope to talk about user interfaces, there
may be no user interface at all, since all the trust environment may be 
hard coded or preinstalled or
whatever. The API is the borderline IMO. I think conforming APIs SHOULD 
permit applications
to set all input values.

For your proposed text it is not clear whether you talk about a user 
interface or the API or
the algorithm or some mixture, or.. What means "The implementation"
 
I think it is out of scope to talk about user interfaces, there may be 
no user interface at all, since
all the trust environment may be hard coded or preinstalled or whatever.
The API is the borderline IMO. I think conforming APIs SHOULD permit 
applications
to set all input values.

Does your comment mean that a comforming implementation of the algorithm
may permit other default values than the defined one to be effective if 
the application
does not specify them. This should not be a normative remark but a hint to
some implementors.

David A. Cooper wrote:
> initial-excluded-subtrees to the set of inputs listed in section 
> 6.1.1, I do not believe that this would require a conforming 
> implementation to be able to validate paths using initial values for 
> permitted_subtrees and excluded_subtrees other than "permit all" and 
> "exclude none".  This would just be an example of an implementation 
> that hard coded the values for the initial-permitted-subtrees and 
> initial-excluded-subtrees inputs.
>
> inputs, I chose initial-any-policy-inhibit for the example since it is 
> a simple boolean and thus much easier to describe.
>
> Dave
>
> Peter Sylvester 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.
>>> (Using the Path Validation Algorithm) and is basically unchanged 
>>> from RFC 3280:
>>>
>>> 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
>>>

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