Subject: Fwd: ldapbis WG last call on draft-ietf-ldapbis-dn-10.txt

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 27 May 2003 20:12:51 -0700

I call your attention to LDAPBIS's WG Last Call of LDAP
String Representation of DNs I-D.  It is hoped that this
I-D addresses the "published table" concerned previously
raised by PKIX'ers.  PKIX'ers are encouraged to review
this draft.  Please address any comments you might have
to the LDAPBIS WG <[email-masked]>.

Kurt (as draft-ietf-ldapbis-dn editor)

>Date: Tue, 27 May 2003 14:12:49 -0700 (PDT)
>From: "RL 'Bob' Morgan" <[email-masked]>
>To: IETF ldapbis WG <[email-masked]>
>Subject: ldapbis WG last call on draft-ietf-ldapbis-dn-10.txt
>Comment: ietf-ldapbis mailing list <http://www.OpenLDAP.org/lists/>
>List-Archive: <http://www.OpenLDAP.org/lists/ietf-ldapbis/>
>
>
>This message initiates a LDAPbis Working Group Last Call on the
>document:
>
>      LDAP: String Representation of Distinguished Names
>             <draft-ietf-ldapbis-dn-10.txt>
>                      4 May 2003
>
>The purpose of this WG Last Call it to ensure that the Working Group has
>achieved consensus that the document is suitable for publication as an
>IETF Draft Standard.
>
>Please review the document for both technical and editorial problems.
>Technical issues should be discussed on this list.  Editorial issues may
>be sent to the document editor.
>
>(Let me point out that a previous version of this document went through WG
>last call quite a while ago.  Subsequently the "short names registry"
>issue was reopened.  The current version of this document reflects
>apparent current WG consensus to support a registry approach; see section
>2.3.  This Last Call is intended to confirm this consensus as well as
>solicit any other review.)
>
>The Last Call period will end on Friday, June 13, 2003.
>
>Upon completion of the last call, the WG chair(s) will take action based
>upon the consensus of the WG.  Possible actions include:
>
>  1) recommending to the IETF Application Area Directors that the
>     document, after possible editorial or other minor changes, be
>     considered by the IESG for publication as a Draft Standard
>     (which generally involves an IETF-wide Last Call); or
>
>  2) requiring that outstanding issues be adequately addressed prior
>     to further action (including, possibly, another Last Call).
>
>Remember that it is our responsibility as Working Group members to
>ensure the quality of our documents and of the Internet Standards
>process.  So, please read and comment!
>
> - RL "Bob" Morgan
>   LDAPbis co-chair

Date: Tue, 27 May 2003 20:12:51 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Fwd: ldapbis WG last call on draft-ietf-ldapbis-dn-10.txt
Sender: [email-masked]

I call your attention to LDAPBIS's WG Last Call of LDAP
String Representation of DNs I-D.  It is hoped that this
I-D addresses the "published table" concerned previously
raised by PKIX'ers.  PKIX'ers are encouraged to review
this draft.  Please address any comments you might have
to the LDAPBIS WG <[email-masked]>.

Kurt (as draft-ietf-ldapbis-dn editor)

>Date: Tue, 27 May 2003 14:12:49 -0700 (PDT)
>From: "RL 'Bob' Morgan" <[email-masked]>
>To: IETF ldapbis WG <[email-masked]>
>Subject: ldapbis WG last call on draft-ietf-ldapbis-dn-10.txt
>Comment: ietf-ldapbis mailing list <http://www.OpenLDAP.org/lists/>
>List-Archive: <http://www.OpenLDAP.org/lists/ietf-ldapbis/>
>
>
>This message initiates a LDAPbis Working Group Last Call on the
>document:
>
>      LDAP: String Representation of Distinguished Names
>             <draft-ietf-ldapbis-dn-10.txt>
>                      4 May 2003
>
>The purpose of this WG Last Call it to ensure that the Working Group has
>achieved consensus that the document is suitable for publication as an
>IETF Draft Standard.
>
>Please review the document for both technical and editorial problems.
>Technical issues should be discussed on this list.  Editorial issues may
>be sent to the document editor.
>
>(Let me point out that a previous version of this document went through WG
>last call quite a while ago.  Subsequently the "short names registry"
>issue was reopened.  The current version of this document reflects
>apparent current WG consensus to support a registry approach; see section
>2.3.  This Last Call is intended to confirm this consensus as well as
>solicit any other review.)
>
>The Last Call period will end on Friday, June 13, 2003.
>
>Upon completion of the last call, the WG chair(s) will take action based
>upon the consensus of the WG.  Possible actions include:
>
>  1) recommending to the IETF Application Area Directors that the
>     document, after possible editorial or other minor changes, be
>     considered by the IESG for publication as a Draft Standard
>     (which generally involves an IETF-wide Last Call); or
>
>  2) requiring that outstanding issues be adequately addressed prior
>     to further action (including, possibly, another Last Call).
>
>Remember that it is our responsibility as Working Group members to
>ensure the quality of our documents and of the Internet Standards
>process.  So, please read and comment!
>
> - RL "Bob" Morgan
>   LDAPbis co-chair

From: "Matt Cooper" <[email-masked]>
To: "'PKIX list'" <[email-masked]>
Subject: RE: RFC 3280: same certificate in a certification path
Date: Fri, 23 May 2003 11:37:38 -0400
Importance: Normal
Sender: [email-masked]

Walt Tuvell noticed and brought to my attention that I left out an important
detail - 

The basic idea is to not re-use keys at the same point in the cert graph, so
the rule I proposed should be "Don't re-use the same key and subject name
pair." This is the same idea (prevents multiple traversals across the
bridge, policy loops, etc.) but still allows a CA to perform a "name change"
on itself should the need arise. (For example, as Walt pointed out, during
migration to DNS naming from X500 naming.)

For those of you reading this (if any) who may be using one of the path
builders I put together, never fear, it is implemented with the Key / DN
pair, not just the key, so name changes should work without a problem.

Matt Cooper
Orion Security Solutions

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Matt Cooper
> Sent: Friday, May 23, 2003 12:32 AM
> To: [email-masked]; 'PKIX list'
> Subject: RE: RFC 3280: same certificate in a certification path
> 
> 
> 
> Very well put!
> 
> Now, what say you to the assertion that there is no need to 
> repeat keys in a path, much less certificates? There are a 
> couple very attractive properties to such a rule such as 
> preventing multiple traversals through a Bridge CA, or 
> preventing "policy loops" like in your example but more 
> complicated - through multiple CAs and looped back via a 
> different path - duplicate certs not required.
> 
> I have yet to encounter a real world example where it was 
> necessary to repeat a key. In fact, the last two path 
> builders I wrote used that rule, and they have yet to run 
> into a snag (as far as I know!) in testing or in the wild as 
> a result of that restriction. Your (and others') thoughts 
> would be welcome!
> 
> Very Best Regards,
> 
> Matt Cooper
> Orion Security Solutions
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Steve Hanna
> > Sent: Monday, May 19, 2003 5:59 AM
> > To: Eric Norman; PKIX list
> > Subject: Re: RFC 3280: same certificate in a certification path
> > 
> > 
> > 
> > Eric Norman wrote:
> > >To say that a path is prohibited or is invalid does not mean
> > that the
> > >answer to the question of trust that you're trying to
> > establish is "not
> > >trusted".  What I think the intent is, and what I think
> > works, is that
> > >when you say a path is prohibited, you mean that it needn't be
> > >considered farther because it will contribute nothing more.
> > 
> > Yes, that's it. There's no reason to consider paths that
> > contain the same certificate twice because nobody can come up 
> > with any real-world scenario where they have any value. But 
> > if we consider them valid there are some rather preposterous 
> > scenarios where the only valid path would be one that 
> > contains the same certificate twice.
> > 
> > For instance, in a path CA1->CA2->CA1->CA2->EE where the user's 
> > acceptable policy is High and policy mapping is enabled and 
> CA1->CA2 
> > has HIGH and TOP SECRET policies and maps HIGH to CONF and 
> TOP SECRET 
> > to Z, CA2->CA1 has CONF policy and maps CONF to TOP SECRET, and 
> > CA2->EE has Z policy. See the example in our paper. This 
> example makes 
> > no real world sense, but it shows that if paths with duplicate
> > certificates are considered valid then path builders must try 
> > them (at least, when policy mapping is involved).
> > 
> > The best solution, as you suggest, is for people to not just
> > stick certs together casually, perform path validation, and 
> > give up if it fails. They should move on to try path 
> > building. The path builder will build a valid path if one can 
> > be built (omitting pointless duplicate certificates). But 
> > there's no problem with declaring paths that contain 
> > duplicate certificates to be invalid.
> > 
> > I'd love to chat more about the interesting theoretical
> > issues that you raised (and I will return to do so), but I 
> > have to run off to Jury Duty today. I'll catch up with you 
> > tomorrow and we can discuss this more.
> > 
> > Thanks,
> > 
> > Steve
> > 
> > >On Fri, 16 May 2003, Steve Hanna wrote:
> > >
> > >> A path that includes the same cert twice might look like this:
> > >>
> > >> CA1 -> CA2 -> CA1 -> CA2 -> EE
> > >
> > >[for reference below].
> > >
> > >> Eric Norman asks why we want to prohibit paths that
> > contain the same
> > >> certificate twice. I agree that there's nothing inherently
> > wrong with
> > >> such a path. But nobody has been able to show any reason why it's
> > >> desirable to support such a path. And if we prohibit such 
> > paths, then
> > >> path builders can be somewhat simpler and more efficient.
> > They don't
> > >> have to consider building paths with loops.
> > >>
> > >> Eric, do you have a good reason why we should not prohibit
> > paths that
> > >> contain the same certificate twice? I don't find
> > >
> > >Because they can happen.  There's nothing that will prevent, and
> > >there's also probably no way to prevent autonomous CAs 
> from creating 
> > >loops in the certificate network.  Ergo, this must be dealt with 
> > >somehow; more below.
> > >
> > >> your argument about sticking two paths together 
> convincing. That's
> > >> not how PKIX path building is generally done, since it 
> > often doesn't
> > >> work (if one of the certs in the first part of the path
> > includes name
> > >> constraints violated by a cert in the second part of the 
> path, for
> > >> instance).
> > >
> > >In fact, the examples chosen here, e.g. the path segment
> > >CA1 -> CA2 -> CA1  (append another -> CA2 if you prefer) are
> > precisely
> > >what happens when two CAs cross certify each other by signing each
> > >others keys (really attesting to each other's
> > >identity) and then publish the fact that they have done so with a 
> > >CrossCertificatePair with both parts filled in (e.g. bridge 
> > stuff and
> > >the like).
> > >
> > >Actually, it's even simpler than that.  Continuing with the
> > distinction
> > >you're trying to make above, you could just as well have a 
> path like
> > >CA1 -> CA2 -> CA2 -> CA2 -> CA2 -> CA3. The same certificate 
> > >(self-signed) appears multiple times. However, this path can 
> > be used to
> > >verify a trust relationship between CA1 and CA3 (just
> > pretend CA2 never
> > >issued the self- signed certificate).
> > >
> > >I think that we're really talking about here is what exactly
> > is meant,
> > >and what is implied, and what will be inferred by implementors when
> > >they see words like "prohibit", "valid" and so forth.
> > >
> > >To say that a path is prohibited or is invalid does not mean
> > that the
> > >answer to the question of trust that you're trying to
> > establish is "not
> > >trusted".  What I think the intent is, and what I think
> > works, is that
> > >when you say a path is prohibited, you mean that it needn't be
> > >considered farther because it will contribute nothing more.
> > >
> > >What my real problem might be is that I think the language
> > could lead
> > >to enough confusion for implementors that they'll get it wrong.
> > >
> > >The implication this has for constraints is that if 
> they're properly
> > >designed (and I think they probably are) then when you 
> > encounter some
> > >constraints a second time (because you've encountered a certificate
> > >again), then applying the contraints again will yield 
> nothing new.  
> > >Actually, what I really think is that this shouldn't even happen 
> > >because you should create a spanning tree or something like 
> > that before
> > >you begin the trust evaluation process; i.e. you should never even
> > >encounter a certificate twice, but if you do, you'll still 
> > get the same
> > >answer as far as trust.  All that's left is to worry about 
> > >termination when you have loops in the certificate graph.
> > >
> > >Hence,
> > >
> > >> P.S. Eric, thanks for tooting your own horn. It's good for us to
> > >> consider and understand earlier work so we don't reinvent things.
> > >
> > >FWIW, I'll say a bit more about garbage collection in LISP. If you 
> > >mimic the simplistic recursive descent -- leave spoor
> > everywhere
> > >-- back out when you encounter it garbage collection
> > algorithm to try
> > >to find a known "trust anchor", then you are guaranteed that:
> > >
> > >(1) you will find a path if one exists, and
> > >
> > >(2) the algorithm will always terminate.
> > >
> > >What you are not guaranteed is that this simplistic
> > algorithm will find
> > >the best path by whatever metric you use to determine what's best.
> > >
> > >> Certificate path building is at heart a graph theory problem.
> > >
> > >And category theory is at the heart of graph theory; however, I not
> > >going to suggest that everyone needs to take time out and read the 
> > >works of Saunders MacLane before discussion can continue :) :) :)
> > >
> > >I do have a "hidden agenda", though.  I will now try to change its
> > >status from covert to overt.  I would like to see sound 
> theoretical 
> > >underpinnings to all this stuff.  That means mathematics, 
> the branch 
> > >called "algebra" in particular.  I'm not claiming that 
> concepts like 
> > >splicing chains together completely provide such 
> > underpinnings, but I
> > >believe that they come real close.  There's a pretty direct
> > translation
> > >between splicing chains and the mathematical concepts of 
> transitive 
> > >relations and composition of functions, and the algorithm 
> above does 
> > >nothing more than compute what is known as a closure or limit.
> > >
> > >> But the problem is complicated by adding constraints to
> > certificates
> > >> and by performance concerns. I recently talked
> > >
> > >What you want is for constraints to have a "monotonic"
> > property. That's
> > >just another way of saying that they'll contribute nothing new if
> > >applied again (well, actually that they won't try to 
> > contradict what's
> > >been done before).
> > >
> > >> with someone who said "Cert path building isn't hard. It's only
> > >> O(n+e) where n is the number of entities and e is the number of 
> > >> certificates." That's true, but you have to download all the 
> > >> certificates in the PKI first! Not very practical in most 
> > >> environments.
> > >
> > >It sounds I'm another one who's says "it's easy", doesn't it?
> > >
> > >I don't think I'm saying that you have to download all the
> > certificates
> > >in the PKI first.  What I think I'm saying is that you
> > aren't going to
> > >have much luck if you try to solve such problems by
> > restrictions of the
> > >possible topologies. The way to do it is to make sure you
> > notice that
> > >you're in a loop.  And when you do notice that, you 
> certainly can't 
> > >give up and pronounce that whole thing untrustworthy; you just try 
> > >something else until you run out of possiblities.
> > >
> > >Now the practical performance problems and the "as yet 
> unknown link"
> > >problems have been introduced.  I'll offer the opinion 
> that the very 
> > >best thing that can to done to alleviate such problems is to 
> > follow the
> > >often written advice to send all certificates to the other
> > end that you
> > >suspect they might need. Every certificate using protocol has
> > >facilities to do this. In the circles where I've heard this 
> > discussed,
> > >I'm having a real hard time understanding why there's such
> > resistance
> > >to doing this.
> > >
> > >
> > >Eric Norman
> > >
> > >	"Congress shall make no law restricting the size of integers
> > >	that may be multiplied together, or the number of times that
> > >	an integer may be multiplied by itself, or the modulus by
> > >	which an integer may be reduced".
> > 
> > 
> 
> 

From: "Matt Cooper" <[email-masked]>
To: <[email-masked]>, "'PKIX list'" <[email-masked]>
Subject: RE: RFC 3280: same certificate in a certification path
Date: Fri, 23 May 2003 00:32:04 -0400
Importance: Normal
Sender: [email-masked]

Very well put!

Now, what say you to the assertion that there is no need to repeat keys in a
path, much less certificates? There are a couple very attractive properties
to such a rule such as preventing multiple traversals through a Bridge CA,
or preventing "policy loops" like in your example but more complicated -
through multiple CAs and looped back via a different path - duplicate certs
not required.

I have yet to encounter a real world example where it was necessary to
repeat a key. In fact, the last two path builders I wrote used that rule,
and they have yet to run into a snag (as far as I know!) in testing or in
the wild as a result of that restriction. Your (and others') thoughts would
be welcome!

Very Best Regards,

Matt Cooper
Orion Security Solutions

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Steve Hanna
> Sent: Monday, May 19, 2003 5:59 AM
> To: Eric Norman; PKIX list
> Subject: Re: RFC 3280: same certificate in a certification path
> 
> 
> 
> Eric Norman wrote:
> >To say that a path is prohibited or is invalid does not mean 
> that the 
> >answer to the question of trust that you're trying to 
> establish is "not 
> >trusted".  What I think the intent is, and what I think 
> works, is that 
> >when you say a path is prohibited, you mean that it needn't be 
> >considered farther because it will contribute nothing more.
> 
> Yes, that's it. There's no reason to consider paths that 
> contain the same certificate twice because nobody can come up 
> with any real-world scenario where they have any value. But 
> if we consider them valid there are some rather preposterous 
> scenarios where the only valid path would be one that 
> contains the same certificate twice.
> 
> For instance, in a path CA1->CA2->CA1->CA2->EE where the
> user's acceptable policy is High and policy mapping is 
> enabled and CA1->CA2 has HIGH and TOP SECRET policies and 
> maps HIGH to CONF and TOP SECRET to Z, CA2->CA1 has CONF 
> policy and maps CONF to TOP SECRET, and CA2->EE has Z policy. 
> See the example in our paper. This example makes no real 
> world sense, but it shows that if paths with duplicate 
> certificates are considered valid then path builders must try 
> them (at least, when policy mapping is involved).
> 
> The best solution, as you suggest, is for people to not just 
> stick certs together casually, perform path validation, and 
> give up if it fails. They should move on to try path 
> building. The path builder will build a valid path if one can 
> be built (omitting pointless duplicate certificates). But 
> there's no problem with declaring paths that contain 
> duplicate certificates to be invalid.
> 
> I'd love to chat more about the interesting theoretical 
> issues that you raised (and I will return to do so), but I 
> have to run off to Jury Duty today. I'll catch up with you 
> tomorrow and we can discuss this more.
> 
> Thanks,
> 
> Steve
> 
> >On Fri, 16 May 2003, Steve Hanna wrote:
> >
> >> A path that includes the same cert twice might look like this:
> >>
> >> CA1 -> CA2 -> CA1 -> CA2 -> EE
> >
> >[for reference below].
> >
> >> Eric Norman asks why we want to prohibit paths that 
> contain the same 
> >> certificate twice. I agree that there's nothing inherently 
> wrong with 
> >> such a path. But nobody has been able to show any reason why it's 
> >> desirable to support such a path. And if we prohibit such 
> paths, then 
> >> path builders can be somewhat simpler and more efficient. 
> They don't 
> >> have to consider building paths with loops.
> >>
> >> Eric, do you have a good reason why we should not prohibit 
> paths that 
> >> contain the same certificate twice? I don't find
> >
> >Because they can happen.  There's nothing that will prevent, and 
> >there's also probably no way to prevent autonomous CAs from creating 
> >loops in the certificate network.  Ergo, this must be dealt with 
> >somehow; more below.
> >
> >> your argument about sticking two paths together convincing. That's 
> >> not how PKIX path building is generally done, since it 
> often doesn't 
> >> work (if one of the certs in the first part of the path 
> includes name 
> >> constraints violated by a cert in the second part of the path, for 
> >> instance).
> >
> >In fact, the examples chosen here, e.g. the path segment
> >CA1 -> CA2 -> CA1  (append another -> CA2 if you prefer) are 
> precisely 
> >what happens when two CAs cross certify each other by signing each 
> >others keys (really attesting to each other's
> >identity) and then publish the fact that they have done so with a 
> >CrossCertificatePair with both parts filled in (e.g. bridge 
> stuff and 
> >the like).
> >
> >Actually, it's even simpler than that.  Continuing with the 
> distinction 
> >you're trying to make above, you could just as well have a path like 
> >CA1 -> CA2 -> CA2 -> CA2 -> CA2 -> CA3. The same certificate 
> >(self-signed) appears multiple times. However, this path can 
> be used to 
> >verify a trust relationship between CA1 and CA3 (just 
> pretend CA2 never 
> >issued the self- signed certificate).
> >
> >I think that we're really talking about here is what exactly 
> is meant, 
> >and what is implied, and what will be inferred by implementors when 
> >they see words like "prohibit", "valid" and so forth.
> >
> >To say that a path is prohibited or is invalid does not mean 
> that the 
> >answer to the question of trust that you're trying to 
> establish is "not 
> >trusted".  What I think the intent is, and what I think 
> works, is that 
> >when you say a path is prohibited, you mean that it needn't be 
> >considered farther because it will contribute nothing more.
> >
> >What my real problem might be is that I think the language 
> could lead 
> >to enough confusion for implementors that they'll get it wrong.
> >
> >The implication this has for constraints is that if they're properly 
> >designed (and I think they probably are) then when you 
> encounter some 
> >constraints a second time (because you've encountered a certificate 
> >again), then applying the contraints again will yield nothing new.  
> >Actually, what I really think is that this shouldn't even happen 
> >because you should create a spanning tree or something like 
> that before 
> >you begin the trust evaluation process; i.e. you should never even 
> >encounter a certificate twice, but if you do, you'll still 
> get the same
> >answer as far as trust.  All that's left is to worry about
> >termination when you have loops in the certificate graph.
> >
> >Hence,
> >
> >> P.S. Eric, thanks for tooting your own horn. It's good for us to 
> >> consider and understand earlier work so we don't reinvent things.
> >
> >FWIW, I'll say a bit more about garbage collection in LISP.
> >If you mimic the simplistic recursive descent -- leave spoor 
> everywhere 
> >-- back out when you encounter it garbage collection 
> algorithm to try 
> >to find a known "trust anchor", then you are guaranteed that:
> >
> >(1) you will find a path if one exists, and
> >
> >(2) the algorithm will always terminate.
> >
> >What you are not guaranteed is that this simplistic 
> algorithm will find 
> >the best path by whatever metric you use to determine what's best.
> >
> >> Certificate path building is at heart a graph theory problem.
> >
> >And category theory is at the heart of graph theory; however, I not 
> >going to suggest that everyone needs to take time out and read the 
> >works of Saunders MacLane before discussion can continue :) :) :)
> >
> >I do have a "hidden agenda", though.  I will now try to change its 
> >status from covert to overt.  I would like to see sound theoretical 
> >underpinnings to all this stuff.  That means mathematics, the branch 
> >called "algebra" in particular.  I'm not claiming that concepts like 
> >splicing chains together completely provide such 
> underpinnings, but I 
> >believe that they come real close.  There's a pretty direct 
> translation
> >between splicing chains and the mathematical concepts of
> >transitive relations and composition of functions, and
> >the algorithm above does nothing more than compute what
> >is known as a closure or limit.
> >
> >> But the problem is complicated by adding constraints to 
> certificates 
> >> and by performance concerns. I recently talked
> >
> >What you want is for constraints to have a "monotonic" 
> property. That's 
> >just another way of saying that they'll contribute nothing new if 
> >applied again (well, actually that they won't try to 
> contradict what's 
> >been done before).
> >
> >> with someone who said "Cert path building isn't hard. It's only 
> >> O(n+e) where n is the number of entities and e is the number of 
> >> certificates." That's true, but you have to download all the 
> >> certificates in the PKI first! Not very practical in most 
> >> environments.
> >
> >It sounds I'm another one who's says "it's easy", doesn't it?
> >
> >I don't think I'm saying that you have to download all the 
> certificates 
> >in the PKI first.  What I think I'm saying is that you 
> aren't going to 
> >have much luck if you try to solve such problems by 
> restrictions of the 
> >possible topologies. The way to do it is to make sure you 
> notice that 
> >you're in a loop.  And when you do notice that, you certainly
> >can't give up and pronounce that whole thing untrustworthy;
> >you just try something else until you run out of possiblities.
> >
> >Now the practical performance problems and the "as yet unknown link" 
> >problems have been introduced.  I'll offer the opinion that the very 
> >best thing that can to done to alleviate such problems is to 
> follow the 
> >often written advice to send all certificates to the other 
> end that you 
> >suspect they might need. Every certificate using protocol has 
> >facilities to do this. In the circles where I've heard this 
> discussed, 
> >I'm having a real hard time understanding why there's such 
> resistance 
> >to doing this.
> >
> >
> >Eric Norman
> >
> >	"Congress shall make no law restricting the size of integers
> >	that may be multiplied together, or the number of times that
> >	an integer may be multiplied by itself, or the modulus by
> >	which an integer may be reduced".
> 
> 

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: questions about RFC 3126
Date: Thu, 22 May 2003 17:40:51 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_002E_01C32089.49DA2F70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Some questions about RFC 3126 "Electronic signature formats for long
term electronic signatures":
 
1.	For a multiple independent signature format, should each
signature have its own X-timestamp (type 1 or type 2)?
2.	When using OCSP for revocation information the X-timestamp must
be of type 1 only?
3.	For a multiple independent signature format, does the Archive
timestamp cover all the signatures or does it have to be one archive
timestamp per signature?
 
Thanks in advance,
 
Miguel A. Rodriguez
Software Engineer
SeguriDATA
Mexico

------=_NextPart_000_002E_01C32089.49DA2F70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Arial Narrow";
	panose-1:2 11 5 6 2 2 2 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1615558362;
	mso-list-type:hybrid;
	mso-list-template-ids:356800280 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Some questions about RFC 3126 &#8220;Electronic =
signature
formats for long term electronic =
signatures&#8221;:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<ol style=3D'mso-margin-top-alt:0cm' start=3D1 type=3D1>
 <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1;tab-stops:list =
36.0pt'><font
     size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>For a
     multiple independent signature format, should each signature have =
its own
     X-timestamp (type 1 or type 2)?<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1;tab-stops:list =
36.0pt'><font
     size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>When
     using OCSP for revocation information the X-timestamp must be of =
type 1
     only?<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1;tab-stops:list =
36.0pt'><font
     size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>For a
     multiple independent signature format, does the Archive timestamp =
cover
     all the signatures or does it have to be one archive timestamp per
     signature?<o:p></o:p></span></font></li>
</ol>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks in advance,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Miguel A. =
Rodriguez</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Software =
Engineer</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>SeguriDATA</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Mexico</span></font><span =
lang=3DES-MX
style=3D'mso-ansi-language:ES-MX'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DES-MX
style=3D'font-size:12.0pt;mso-ansi-language:ES-MX'><o:p>&nbsp;</o:p></spa=
n></font></p>

</div>

</body>

</html>

------=_NextPart_000_002E_01C32089.49DA2F70--

Date: Thu, 22 May 2003 10:02:23 -0700
From: [email-masked] (Terry Hayes)
Subject: Name Constraints Processing
To: [email-masked]
Organization: Netscape
Sender: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
<font size="2" face="Arial,sans-serif"><font face="Arial,sans-serif">RFC
3280 seems to
be unclear as to the handling of certain unusual cases that may be
encountered while processing the Name Constraints extension.&nbsp; While
these cases are not likely to be seen in real deployments, the
certificate processing code needs to respond to them correctly, both to
avoid incorrect behavior of the application and to avoid introducing
security holes.&nbsp; I'll describe each situation below along with my best
guess at the correct handling.&nbsp; I'd appreciate comments.<br>
<br>
1. Name constraints containing an empty Directory Name sequence<br>
<br>
What is the correct processing of a name constraint extension that
contains an empty sequence in the directoryName choice?<br>
<br>
The empty sequence value for a directory name is used in other places
in this RFC to indicate that no name is present.&nbsp; However, here I think
it means that the constraint matches all possible names.&nbsp; Therefore, in
the permitted subtrees field, this allows certificates to be issued to
any directory name (equivalent to no constraint), and in the excluded
subtrees field, prevents certificates from being issued that contain
any directory name.<br>
<br>
2.&nbsp; Name constraints with other empty values<br>
<br>
What is the meaning of an empty (zero length) value for the RFC822
name, DNS name, Uniform Resource Identifier and IP Address forms of a
name constraint extension?<br>
<br>
An empty value in these fields might be interpreted as matching all
names of the corresponding type.&nbsp; Again, this is not very useful in the
permitted subtrees area, but might be use to disallow all names of that
type by including the empty value in the excluded subtrees field.<br>
<br>
For RFC822, DNS and URI types, the empty value seems equivalent to "."
(just the dot).&nbsp; Do current implementations interpret that string as
matching all names?&nbsp; For IP addresses, there is already a mechanism to
match all names (an all-zero "subnet" mask value) so I would be tempted
to declare that an empty value is invalid (see the following question).<br>
<br>
3. Name constraints with badly formed name values<br>
<br>
What is the correct handling of a name constraint that contains invalid
data?&nbsp; Should the constraint value ever match?&nbsp; What if the incorrect
value is in the excluded subtrees field?<br>
<br>
</font></font><font size="2" face="Arial,sans-serif"><font
 face="Arial,sans-serif">It's possible for a value in a name constraint
to be invalid for that type of name. For example, an RFC822
name might have two '@' characters (such as
<a class="moz-txt-link-rfc2396E" href="mailto:terry@[email-masked]">"terry@[email-masked]"</a>).&nbsp;
Also, the matching rule for the IP
address type cannot be applied if the value has an incorrect length.<br>
<br>
Since it is the CAs responsibility to put the correct values into the
name constraints that are needed to enforce the issuance policy, I
think it is reasonable for applications to ignore name constraints
values that don't make sense.<br>
</font></font><font size="2" face="Arial,sans-serif"><font
 face="Arial,sans-serif"><br>
Thanks in advance for any comments or clarification you can provide.<br>
<br>
Terry Hayes<br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
<br>
</font></font><font face="Arial,sans-serif"><font size="2">
</font></font>
</body>
</html>

From: Steve Hanna <[email-masked]>
Date: Mon, 19 May 2003 05:59:29 -0400
To: "Eric Norman" <[email-masked]>, "PKIX list" <[email-masked]>
Reply-To: <[email-masked]>
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

Eric Norman wrote:
>To say that a path is prohibited or is invalid does not mean
>that the answer to the question of trust that you're trying
>to establish is "not trusted".  What I think the intent is,
>and what I think works, is that when you say a path is prohibited,
>you mean that it needn't be considered farther because it will
>contribute nothing more.

Yes, that's it. There's no reason to consider paths that
contain the same certificate twice because nobody can come
up with any real-world scenario where they have any value.
But if we consider them valid there are some rather preposterous
scenarios where the only valid path would be one that contains
the same certificate twice.

For instance, in a path CA1->CA2->CA1->CA2->EE where the
user's acceptable policy is High and policy mapping is enabled
and CA1->CA2 has HIGH and TOP SECRET policies and maps HIGH to
CONF and TOP SECRET to Z, CA2->CA1 has CONF policy and maps
CONF to TOP SECRET, and CA2->EE has Z policy. See the example
in our paper. This example makes no real world sense, but it
shows that if paths with duplicate certificates are considered
valid then path builders must try them (at least, when policy
mapping is involved).

The best solution, as you suggest, is for people to not just
stick certs together casually, perform path validation, and
give up if it fails. They should move on to try path building.
The path builder will build a valid path if one can be built
(omitting pointless duplicate certificates). But there's no
problem with declaring paths that contain duplicate certificates
to be invalid.

I'd love to chat more about the interesting theoretical issues
that you raised (and I will return to do so), but I have to
run off to Jury Duty today. I'll catch up with you tomorrow
and we can discuss this more.

Thanks,

Steve

>On Fri, 16 May 2003, Steve Hanna wrote:
>
>> A path that includes the same cert twice might look like this:
>>
>> CA1 -> CA2 -> CA1 -> CA2 -> EE
>
>[for reference below].
>
>> Eric Norman asks why we want to prohibit paths that contain
>> the same certificate twice. I agree that there's nothing
>> inherently wrong with such a path. But nobody has been able
>> to show any reason why it's desirable to support such a path.
>> And if we prohibit such paths, then path builders can be
>> somewhat simpler and more efficient. They don't have to
>> consider building paths with loops.
>>
>> Eric, do you have a good reason why we should not prohibit
>> paths that contain the same certificate twice? I don't find
>
>Because they can happen.  There's nothing that will prevent,
>and there's also probably no way to prevent autonomous CAs
>from creating loops in the certificate network.  Ergo, this
>must be dealt with somehow; more below.
>
>> your argument about sticking two paths together convincing.
>> That's not how PKIX path building is generally done, since
>> it often doesn't work (if one of the certs in the first part
>> of the path includes name constraints violated by a cert
>> in the second part of the path, for instance).
>
>In fact, the examples chosen here, e.g. the path segment
>CA1 -> CA2 -> CA1  (append another -> CA2 if you prefer) are
>precisely what happens when two CAs cross certify each other
>by signing each others keys (really attesting to each other's
>identity) and then publish the fact that they have done so with
>a CrossCertificatePair with both parts filled in (e.g. bridge
>stuff and the like).
>
>Actually, it's even simpler than that.  Continuing with the
>distinction you're trying to make above, you could just as
>well have a path like CA1 -> CA2 -> CA2 -> CA2 -> CA2 -> CA3.
>The same certificate (self-signed) appears multiple times.
>However, this path can be used to verify a trust relationship
>between CA1 and CA3 (just pretend CA2 never issued the self-
>signed certificate).
>
>I think that we're really talking about here is what exactly
>is meant, and what is implied, and what will be inferred by
>implementors when they see words like "prohibit", "valid"
>and so forth.
>
>To say that a path is prohibited or is invalid does not mean
>that the answer to the question of trust that you're trying
>to establish is "not trusted".  What I think the intent is,
>and what I think works, is that when you say a path is prohibited,
>you mean that it needn't be considered farther because it will
>contribute nothing more.
>
>What my real problem might be is that I think the language
>could lead to enough confusion for implementors that they'll
>get it wrong.
>
>The implication this has for constraints is that if they're
>properly designed (and I think they probably are) then when
>you encounter some constraints a second time (because you've
>encountered a certificate again), then applying the contraints
>again will yield nothing new.  Actually, what I really think
>is that this shouldn't even happen because you should create
>a spanning tree or something like that before you begin the
>trust evaluation process; i.e. you should never even encounter
>a certificate twice, but if you do, you'll still get the same
>answer as far as trust.  All that's left is to worry about
>termination when you have loops in the certificate graph.
>
>Hence,
>
>> P.S. Eric, thanks for tooting your own horn. It's good for us
>> to consider and understand earlier work so we don't reinvent
>> things.
>
>FWIW, I'll say a bit more about garbage collection in LISP.
>If you mimic the simplistic recursive descent -- leave spoor
>everywhere -- back out when you encounter it garbage collection
>algorithm to try to find a known "trust anchor", then you are
>guaranteed that:
>
>(1) you will find a path if one exists, and
>
>(2) the algorithm will always terminate.
>
>What you are not guaranteed is that this simplistic algorithm
>will find the best path by whatever metric you use to determine
>what's best.
>
>> Certificate path building is at heart a graph theory problem.
>
>And category theory is at the heart of graph theory; however,
>I not going to suggest that everyone needs to take time out
>and read the works of Saunders MacLane before discussion can
>continue :) :) :)
>
>I do have a "hidden agenda", though.  I will now try to change
>its status from covert to overt.  I would like to see sound
>theoretical underpinnings to all this stuff.  That means
>mathematics, the branch called "algebra" in particular.  I'm
>not claiming that concepts like splicing chains together
>completely provide such underpinnings, but I believe that
>they come real close.  There's a pretty direct translation
>between splicing chains and the mathematical concepts of
>transitive relations and composition of functions, and
>the algorithm above does nothing more than compute what
>is known as a closure or limit.
>
>> But the problem is complicated by adding constraints to
>> certificates and by performance concerns. I recently talked
>
>What you want is for constraints to have a "monotonic" property.
>That's just another way of saying that they'll contribute
>nothing new if applied again (well, actually that they won't
>try to contradict what's been done before).
>
>> with someone who said "Cert path building isn't hard. It's
>> only O(n+e) where n is the number of entities and e is the
>> number of certificates." That's true, but you have to download
>> all the certificates in the PKI first! Not very practical in
>> most environments.
>
>It sounds I'm another one who's says "it's easy", doesn't it?
>
>I don't think I'm saying that you have to download all the
>certificates in the PKI first.  What I think I'm saying is
>that you aren't going to have much luck if you try to solve
>such problems by restrictions of the possible topologies.
>The way to do it is to make sure you notice that you're
>in a loop.  And when you do notice that, you certainly
>can't give up and pronounce that whole thing untrustworthy;
>you just try something else until you run out of possiblities.
>
>Now the practical performance problems and the "as yet unknown
>link" problems have been introduced.  I'll offer the opinion
>that the very best thing that can to done to alleviate such
>problems is to follow the often written advice to send all
>certificates to the other end that you suspect they might need.
>Every certificate using protocol has facilities to do this.
>In the circles where I've heard this discussed, I'm having a
>real hard time understanding why there's such resistance to
>doing this.
>
>
>Eric Norman
>
>	"Congress shall make no law restricting the size of integers
>	that may be multiplied together, or the number of times that
>	an integer may be multiplied by itself, or the modulus by
>	which an integer may be reduced".

Date: Mon, 19 May 2003 16:00:48 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

Eric Norman <[email-masked]> writes:

>Attached is a DER encoded PKCS7 "certs only" blob with two CAs that have
>mutually signed for each other.  Does that help?  I know it's not everything
>you're looking for.  I suppose I can make more if we're on the right track
>here.

Hmm, interesting.  I'm on a minimally-configued Windows box at the moment so I
can't feed it to too many things, but Windows displays this as CA1 -> CA2 ->
CA1 and can't verify it because the issuer of the first instance of CA1 can't
be found.  Mozilla hands it off to Windows, with the same result (hmm, it can
import certs but apparently not full chains).  cryptlib sees CA1 -> CA2 (or
CA2 -> CA1, it uses hinting to determine the leaf cert, e.g. the
issuerAndSerialNumber in the signed data, if there's no hint available it
canonicalises the certs into a chain and takes the leaf as the first leaf-
candidate it finds) and validates it once you mark the root as trusted.

Could you do one with an alternating sequence of CA1 and CA2?  I'd be
interested in seeing what response that produces.

Peter.

Date: Sun, 18 May 2003 21:13:54 -0500 (CDT)
From: Eric Norman <[email-masked]>
To: PKIX list <[email-masked]>
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---2140662931-1462719925-1053310434=:11100
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 18 May 2003, Peter Gutmann wrote:

> Does anyone have some cert chains (PKCS #7) with these kinds of
> characteristics?  It'd be nice to have some test vectors for this sort of
> thing (with a few variations, e.g. CA1 -> CA2 -> CA1, CA1 -> CA2 -> CA1 -> CA2
> -> CA1 -> CA2, CA1 -> CA2 -> CA2 -> CA2) to play with, but without a lot of
> custom hacking it would be quite difficult to create with the tools I have now
> (they simply won't allow something like this, for the reasons I gave earlier).

Attached is a DER encoded PKCS7 "certs only" blob with two CAs that
have mutually signed for each other.  Does that help?  I know it's
not everything you're looking for.  I suppose I can make more if
we're on the right track here.

Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".

---2140662931-1462719925-1053310434=:11100
Content-Type: APPLICATION/octet-stream; name="both.p7c"
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: Mutually signed CA certs
Content-Disposition: attachment; filename="both.p7c"

---2140662931-1462719925-1053310434=:11100--

Date: Sun, 18 May 2003 17:38:19 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

Eric Norman <[email-masked]> writes:

>In fact, the examples chosen here, e.g. the path segment CA1 -> CA2 -> CA1
>(append another -> CA2 if you prefer) are precisely what happens when two CAs
>cross certify each other by signing each others keys (really attesting to
>each other's identity) and then publish the fact that they have done so with
>a CrossCertificatePair with both parts filled in (e.g. bridge stuff and the
>like).

Does anyone have some cert chains (PKCS #7) with these kinds of
characteristics?  It'd be nice to have some test vectors for this sort of
thing (with a few variations, e.g. CA1 -> CA2 -> CA1, CA1 -> CA2 -> CA1 -> CA2
-> CA1 -> CA2, CA1 -> CA2 -> CA2 -> CA2) to play with, but without a lot of
custom hacking it would be quite difficult to create with the tools I have now
(they simply won't allow something like this, for the reasons I gave earlier).

Peter.

Date: Sat, 17 May 2003 18:53:53 -0500 (CDT)
From: Eric Norman <[email-masked]>
To: PKIX list <[email-masked]>
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---2140662931-719358168-1053215637=:11100
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 16 May 2003, Steve Hanna wrote:

> A path that includes the same cert twice might look like this:
>
> CA1 -> CA2 -> CA1 -> CA2 -> EE

[for reference below].

> Eric Norman asks why we want to prohibit paths that contain
> the same certificate twice. I agree that there's nothing
> inherently wrong with such a path. But nobody has been able
> to show any reason why it's desirable to support such a path.
> And if we prohibit such paths, then path builders can be
> somewhat simpler and more efficient. They don't have to
> consider building paths with loops.
>
> Eric, do you have a good reason why we should not prohibit
> paths that contain the same certificate twice? I don't find

Because they can happen.  There's nothing that will prevent,
and there's also probably no way to prevent autonomous CAs
from creating loops in the certificate network.  Ergo, this
must be dealt with somehow; more below.

> your argument about sticking two paths together convincing.
> That's not how PKIX path building is generally done, since
> it often doesn't work (if one of the certs in the first part
> of the path includes name constraints violated by a cert
> in the second part of the path, for instance).

In fact, the examples chosen here, e.g. the path segment
CA1 -> CA2 -> CA1  (append another -> CA2 if you prefer) are
precisely what happens when two CAs cross certify each other
by signing each others keys (really attesting to each other's
identity) and then publish the fact that they have done so with
a CrossCertificatePair with both parts filled in (e.g. bridge
stuff and the like).

Actually, it's even simpler than that.  Continuing with the
distinction you're trying to make above, you could just as
well have a path like CA1 -> CA2 -> CA2 -> CA2 -> CA2 -> CA3.
The same certificate (self-signed) appears multiple times.
However, this path can be used to verify a trust relationship
between CA1 and CA3 (just pretend CA2 never issued the self-
signed certificate).

I think that we're really talking about here is what exactly
is meant, and what is implied, and what will be inferred by
implementors when they see words like "prohibit", "valid"
and so forth.

To say that a path is prohibited or is invalid does not mean
that the answer to the question of trust that you're trying
to establish is "not trusted".  What I think the intent is,
and what I think works, is that when you say a path is prohibited,
you mean that it needn't be considered farther because it will
contribute nothing more.

What my real problem might be is that I think the language
could lead to enough confusion for implementors that they'll
get it wrong.

The implication this has for constraints is that if they're
properly designed (and I think they probably are) then when
you encounter some constraints a second time (because you've
encountered a certificate again), then applying the contraints
again will yield nothing new.  Actually, what I really think
is that this shouldn't even happen because you should create
a spanning tree or something like that before you begin the
trust evaluation process; i.e. you should never even encounter
a certificate twice, but if you do, you'll still get the same
answer as far as trust.  All that's left is to worry about
termination when you have loops in the certificate graph.

Hence,

> P.S. Eric, thanks for tooting your own horn. It's good for us
> to consider and understand earlier work so we don't reinvent
> things.

FWIW, I'll say a bit more about garbage collection in LISP.
If you mimic the simplistic recursive descent -- leave spoor
everywhere -- back out when you encounter it garbage collection
algorithm to try to find a known "trust anchor", then you are
guaranteed that:

(1) you will find a path if one exists, and

(2) the algorithm will always terminate.

What you are not guaranteed is that this simplistic algorithm
will find the best path by whatever metric you use to determine
what's best.

> Certificate path building is at heart a graph theory problem.

And category theory is at the heart of graph theory; however,
I not going to suggest that everyone needs to take time out
and read the works of Saunders MacLane before discussion can
continue :) :) :)

I do have a "hidden agenda", though.  I will now try to change
its status from covert to overt.  I would like to see sound
theoretical underpinnings to all this stuff.  That means
mathematics, the branch called "algebra" in particular.  I'm
not claiming that concepts like splicing chains together
completely provide such underpinnings, but I believe that
they come real close.  There's a pretty direct translation
between splicing chains and the mathematical concepts of
transitive relations and composition of functions, and
the algorithm above does nothing more than compute what
is known as a closure or limit.

> But the problem is complicated by adding constraints to
> certificates and by performance concerns. I recently talked

What you want is for constraints to have a "monotonic" property.
That's just another way of saying that they'll contribute
nothing new if applied again (well, actually that they won't
try to contradict what's been done before).

> with someone who said "Cert path building isn't hard. It's
> only O(n+e) where n is the number of entities and e is the
> number of certificates." That's true, but you have to download
> all the certificates in the PKI first! Not very practical in
> most environments.

It sounds I'm another one who's says "it's easy", doesn't it?

I don't think I'm saying that you have to download all the
certificates in the PKI first.  What I think I'm saying is
that you aren't going to have much luck if you try to solve
such problems by restrictions of the possible topologies.
The way to do it is to make sure you notice that you're
in a loop.  And when you do notice that, you certainly
can't give up and pronounce that whole thing untrustworthy;
you just try something else until you run out of possiblities.

Now the practical performance problems and the "as yet unknown
link" problems have been introduced.  I'll offer the opinion
that the very best thing that can to done to alleviate such
problems is to follow the often written advice to send all
certificates to the other end that you suspect they might need.
Every certificate using protocol has facilities to do this.
In the circles where I've heard this discussed, I'm having a
real hard time understanding why there's such resistance to
doing this.

Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".

---2140662931-719358168-1053215637=:11100
Content-Type: APPLICATION/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: BASE64
Content-Description: S/MIME Cryptographic Signature
Content-Disposition: attachment; filename="smime.p7s"

---2140662931-719358168-1053215637=:11100--

Date: Fri, 16 May 2003 11:28:32 -0400
From: Steve Hanna <[email-masked]>
To: Eric Norman <[email-masked]>
CC: PKIX list <[email-masked]>
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

Oh, darn! We've had a problem since the first email
in this thread.

Takashi ITO wrote:
> This means, for example, "CA1 -> CA2 -> CA1 -> EE" is not a valid
> certification path.

Actually, that's a fine path. Each of the arrows is a cert.
And clearly each of these three certs is unique, since each
one has a different subject-issuer pair: (CA1, CA2), (CA2, CA1),
(CA1, EE). So this isn't a problem.

A path that includes the same cert twice might look like this:

CA1 -> CA2 -> CA1 -> CA2 -> EE

Then the first and the third certificates would probably be
the same (although they might not be if CA1 has issued more
than one cert for CA2). If they were the same, then that would
not be allowed per X.509 (2000) but it would be allowed per
RFC 3280.

Eric Norman asks why we want to prohibit paths that contain
the same certificate twice. I agree that there's nothing
inherently wrong with such a path. But nobody has been able
to show any reason why it's desirable to support such a path.
And if we prohibit such paths, then path builders can be
somewhat simpler and more efficient. They don't have to
consider building paths with loops.

Eric, do you have a good reason why we should not prohibit
paths that contain the same certificate twice? I don't find
your argument about sticking two paths together convincing.
That's not how PKIX path building is generally done, since
it often doesn't work (if one of the certs in the first part
of the path includes name constraints violated by a cert
in the second part of the path, for instance).

Note that this is somewhat of a moot point. RFC 3280 is a
profile of X.509 and X.509 now prohibits such paths, so we
really need to do so as well unless we want to try to
convince the X.509 folks to reverse themselves on this.
I'd need to see a pretty good argument to consider doing that.

-Steve

P.S. Eric, thanks for tooting your own horn. It's good for us
to consider and understand earlier work so we don't reinvent
things.

Certificate path building is at heart a graph theory problem.
But the problem is complicated by adding constraints to
certificates and by performance concerns. I recently talked
with someone who said "Cert path building isn't hard. It's
only O(n+e) where n is the number of entities and e is the
number of certificates." That's true, but you have to download
all the certificates in the PKI first! Not very practical in
most environments.

Eric Norman wrote:
> 
> On Thu, 15 May 2003, Steve Hanna wrote:
> 
> > In my opinion, RFC 3280 should be changed (in a
> > successor RFC) to include a requirement that a valid
> > certification path cannot include the same certificate
> > twice. This has been discussed on several occasions and
> > nobody has been able to come up with a good reason to
> > allow such a path to be valid. Also, we want to maintain
> > consistency with X.509. And allowing duplicate certificates
> > makes path building more difficult.
> >
> > Takashi ITO wrote:
> > >
> > > I have a question about "certification path" in RFC 3280.
> > >
> > > In X.509(4th) "10.1 Path Processing inputs", text says:
> > >
> > >     The inputs to the certification path processing procedure are:
> > >
> > >     a)  a set of certificates comprising a certification path;
> > >     NOTE - Each certificate in a certification path is unique.
> > >     A path that contains the same certificate two or more times
> > >     is not a valid certification path.
> > >
> > >     ...(snip)
> > >
> > > This means, for example, "CA1 -> CA2 -> CA1 -> EE" is not a valid
> > > certification path.
> 
> I have two "valid" certification paths, for instance, the path CA1 -> CA2,
> and also the path CA2 -> CA1 -> EE.  Now I splice them together by doing
> no more than recognizing that the end of one path is identical to the
> beginning of the other.  I cannot imagine why the resulting longer path
> should now be considered "invalid".  Note that if the second path is
> CA2 -> CA3 -> EE, there's no reason for complaint.  In other words, if
> I start with "valid" things and do something "valid" with them, it sure
> does seem like the result should also be "valid".
> 
> I can imagine that the result of such splicing might be less efficient,
> or redundant, or something like that.  But to now call it "invalid"?
> That seems stange.
> 
> But you say, "but that allows loops in the path".  So what?  You already
> have loops in the path; it's just that they're of length 1 (or 0, if you
> prefer) and they're called self-signed certificates.
> 
> In the above example, two different CAs mutually "do their thing" with
> each other.  It seems to me that this would make the keys of each more
> trustworthy, not less, and certainly not "invalid".
> 
> The path discovery problem has been known for many, many years and has
> been solved by every LISP garbage collector, for instance.  And now I'll
> go off on a toot-my-own-horn tangent and point out that if you want to
> see some actual code, you can see some that I wrote 30 years ago for the
> Univac 1108 LISP system on the History of LISP site at
> 
>    http://www.frobenius.com/univac.htm
> 
> Eric Norman
> 
>                 "I may be just a butterfly,
>                  but watch out if I flap my wings".

Date: Fri, 16 May 2003 15:50:58 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: RFC 3280: same certificate in a certification path
Cc: [email-masked]
Sender: [email-masked]

Richard Levitte - VMS Whacker <[email-masked]> writes:

>Heh, to forbid those may seem silly, but you have to admit that it gives a
>good hint that "CA1 -> EE" is the better way to go, wouldn't you agree?  Why
>would you at all want to take the longer path?  Or is there some policy magic
>that requires the long path to be processed?

See "Building Certifications Paths: Forward vs. Reverse" from NDSS '01.

Having said that, even trying to work with a PKI in which loops are possible
is about as sound as playing Irish roulette (a variant of Russian roulette in
which you use six bullets and hope the gun jams).  Given the flakiness of
current software in handling even relatively straightforward cert paths,
trying to rely on any kind of consistent behaviour in the face of loops in
paths is practically suicidal, you may as well flip a coin to determine the
outcome.

Peter.

Date: Thu, 15 May 2003 14:09:00 -0500 (CDT)
From: Eric Norman <[email-masked]>
To: PKIX list <[email-masked]>
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

On Thu, 15 May 2003, Steve Hanna wrote:

> In my opinion, RFC 3280 should be changed (in a
> successor RFC) to include a requirement that a valid
> certification path cannot include the same certificate
> twice. This has been discussed on several occasions and
> nobody has been able to come up with a good reason to
> allow such a path to be valid. Also, we want to maintain
> consistency with X.509. And allowing duplicate certificates
> makes path building more difficult.
>
> Takashi ITO wrote:
> >
> > I have a question about "certification path" in RFC 3280.
> >
> > In X.509(4th) "10.1 Path Processing inputs", text says:
> >
> >     The inputs to the certification path processing procedure are:
> >
> >     a)  a set of certificates comprising a certification path;
> >     NOTE - Each certificate in a certification path is unique.
> >     A path that contains the same certificate two or more times
> >     is not a valid certification path.
> >
> >     ...(snip)
> >
> > This means, for example, "CA1 -> CA2 -> CA1 -> EE" is not a valid
> > certification path.

I have two "valid" certification paths, for instance, the path CA1 -> CA2,
and also the path CA2 -> CA1 -> EE.  Now I splice them together by doing
no more than recognizing that the end of one path is identical to the
beginning of the other.  I cannot imagine why the resulting longer path
should now be considered "invalid".  Note that if the second path is
CA2 -> CA3 -> EE, there's no reason for complaint.  In other words, if
I start with "valid" things and do something "valid" with them, it sure
does seem like the result should also be "valid".

I can imagine that the result of such splicing might be less efficient,
or redundant, or something like that.  But to now call it "invalid"?
That seems stange.

But you say, "but that allows loops in the path".  So what?  You already
have loops in the path; it's just that they're of length 1 (or 0, if you
prefer) and they're called self-signed certificates.

In the above example, two different CAs mutually "do their thing" with
each other.  It seems to me that this would make the keys of each more
trustworthy, not less, and certainly not "invalid".

The path discovery problem has been known for many, many years and has
been solved by every LISP garbage collector, for instance.  And now I'll
go off on a toot-my-own-horn tangent and point out that if you want to
see some actual code, you can see some that I wrote 30 years ago for the
Univac 1108 LISP system on the History of LISP site at

   http://www.frobenius.com/univac.htm

Eric Norman

		"I may be just a butterfly,
		 but watch out if I flap my wings".

Date: Thu, 15 May 2003 13:39:34 -0400
From: Steve Hanna <[email-masked]>
To: PKIX List <[email-masked]>
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

The ISOC web site seems to have gone down suddenly.
It must be the incredible load of everyone downloading
our paper. ;-)

If you want a copy of the paper, send me a note
and I'll send you the PDF file by email.

-Steve

Steve Hanna wrote:
> 
> Yes, it's "policy magic". Because of policy mapping,
> it is possible that a path "CA1 -> CA2 -> CA1 -> EE"
> might be considered valid under the existing RFC 3280
> validation algorithm while "CA1 -> EE" would not. For
> an example, see section 5 of our paper from NDSS '01:
> 
> http://www.isoc.org/isoc/conferences/ndss/01/2001/papers/elley.pdf
> 
> However, nobody has yet demonstrated that this is a
> useful feature of the RFC 3280 validation algorithm.
> In fact, there seems to be a general consensus that
> it is harmful. For instance, allowing such loops means
> that path building software must consider the possibility
> that a loop (or maybe several loops) might be required
> to build a valid path between two entities. Declaring
> that a valid certification path cannot contain the same
> certificate more than once solves this.
> 
> -Steve
> 
> Richard Levitte - VMS Whacker wrote:
> >
> > In message <[email-masked]> on Thu, 15 May 2003 20:58:18 +0900, Takashi ITO <[email-masked]> said:
> >
> > takashim> I have a question about "certification path" in RFC 3280.
> > takashim>
> > takashim> In X.509(4th) "10.1 Path Processing inputs", text says:
> > takashim>
> > takashim>     The inputs to the certification path processing procedure are:
> > takashim>
> > takashim>     a)  a set of certificates comprising a certification path;
> > takashim>     NOTE - Each certificate in a certification path is unique.
> > takashim>     A path that contains the same certificate two or more times
> > takashim>     is not a valid certification path.
> > takashim>
> > takashim>     ...(snip)
> > takashim>
> > takashim> This means, for example, "CA1 -> CA2 -> CA1 -> EE" is not a valid
> > takashim> certification path.
> >
> > Heh, to forbid those may seem silly, but you have to admit that it
> > gives a good hint that "CA1 -> EE" is the better way to go, wouldn't
> > you agree?  Why would you at all want to take the longer path?  Or is
> > there some policy magic that requires the long path to be processed?
> >
> > --
> > Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
> > Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
> > T: +46-708-26 53 44 |                             | SWEDEN
> >      "Price, performance, quality...  choose the two you like"

Date: Thu, 15 May 2003 13:36:48 -0400
From: "David A. Cooper" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: X.509 path validation test suite
Sender: [email-masked]

All,

NIST is working in conjunction with NSA and DigitalNet to develop a 
comprehensive X.509 path validation test suite.  This test suite is 
designed to cover most of the features specified in X.509 and RFC 3280.  
NIST intends to reference a subset of the tests in this test suite in a 
PKI Client Protection Profile that is currently under development.  In 
addition, we would like to see this test suite used as the basis for 
demonstrating product interoperability as required to elevate RFC 3280 
to the level of Draft Standard.

The test suite, including descriptions of the tests and all required 
test data, may be obtained from 
http://csrc.nist.gov/pki/testing/x509paths.html.

A mail list has been established for the submission of comments and to 
enable discussion of the test suite.  You may subscribe to the list by 
sending a message to [email-masked] with the following in the body of 
the message: "subscribe pkits your name".  (Substitute your actual name 
for the string "your name".)  Listproc will use the return address from 
the header of your e-mail message.  You must be subscribed to the mail 
list in order to send a message to it, however, the archive will be 
available at http://www.nist.gov/itl/div896/emaildir/pkits/maillist.html 
for everyone to read.

Please submit any comments or suggestions on the test suite by June 27, 
2003.

Thanks,

David Cooper

Date: Thu, 15 May 2003 12:18:54 -0400
From: Steve Hanna <[email-masked]>
To: Richard Levitte - VMS Whacker <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

Yes, it's "policy magic". Because of policy mapping,
it is possible that a path "CA1 -> CA2 -> CA1 -> EE"
might be considered valid under the existing RFC 3280
validation algorithm while "CA1 -> EE" would not. For
an example, see section 5 of our paper from NDSS '01:

http://www.isoc.org/isoc/conferences/ndss/01/2001/papers/elley.pdf

However, nobody has yet demonstrated that this is a
useful feature of the RFC 3280 validation algorithm.
In fact, there seems to be a general consensus that
it is harmful. For instance, allowing such loops means
that path building software must consider the possibility
that a loop (or maybe several loops) might be required
to build a valid path between two entities. Declaring
that a valid certification path cannot contain the same
certificate more than once solves this.

-Steve

Richard Levitte - VMS Whacker wrote:
> 
> In message <[email-masked]> on Thu, 15 May 2003 20:58:18 +0900, Takashi ITO <[email-masked]> said:
> 
> takashim> I have a question about "certification path" in RFC 3280.
> takashim>
> takashim> In X.509(4th) "10.1 Path Processing inputs", text says:
> takashim>
> takashim>     The inputs to the certification path processing procedure are:
> takashim>
> takashim>     a)  a set of certificates comprising a certification path;
> takashim>     NOTE - Each certificate in a certification path is unique.
> takashim>     A path that contains the same certificate two or more times
> takashim>     is not a valid certification path.
> takashim>
> takashim>     ...(snip)
> takashim>
> takashim> This means, for example, "CA1 -> CA2 -> CA1 -> EE" is not a valid
> takashim> certification path.
> 
> Heh, to forbid those may seem silly, but you have to admit that it
> gives a good hint that "CA1 -> EE" is the better way to go, wouldn't
> you agree?  Why would you at all want to take the longer path?  Or is
> there some policy magic that requires the long path to be processed?
> 
> --
> Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
> Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
> T: +46-708-26 53 44 |                             | SWEDEN
>      "Price, performance, quality...  choose the two you like"

Date: Thu, 15 May 2003 17:06:17 +0200 (CEST)
To: [email-masked]
CC: [email-masked]
Subject: Re: RFC 3280: same certificate in a certification path
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Thu, 15 May 2003 20:58:18 +0900, Takashi ITO <[email-masked]> said:

takashim> I have a question about "certification path" in RFC 3280.
takashim> 
takashim> In X.509(4th) "10.1 Path Processing inputs", text says:
takashim> 
takashim>     The inputs to the certification path processing procedure are:
takashim> 
takashim>     a)  a set of certificates comprising a certification path;
takashim>     NOTE - Each certificate in a certification path is unique.
takashim>     A path that contains the same certificate two or more times
takashim>     is not a valid certification path.
takashim> 
takashim>     ...(snip)
takashim> 
takashim> This means, for example, "CA1 -> CA2 -> CA1 -> EE" is not a valid
takashim> certification path.

Heh, to forbid those may seem silly, but you have to admit that it
gives a good hint that "CA1 -> EE" is the better way to go, wouldn't
you agree?  Why would you at all want to take the longer path?  Or is
there some policy magic that requires the long path to be processed?

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Thu, 15 May 2003 11:06:26 -0400
From: Steve Hanna <[email-masked]>
To: Takashi ITO <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [email-masked]

In my opinion, RFC 3280 should be changed (in a
successor RFC) to include a requirement that a valid
certification path cannot include the same certificate
twice. This has been discussed on several occasions and
nobody has been able to come up with a good reason to
allow such a path to be valid. Also, we want to maintain
consistency with X.509. And allowing duplicate certificates
makes path building more difficult.

I don't think there should be any problem with making
this change when RFC 3280 is next revised, since I
suspect nobody is counting on the current behavior.
And I believe that you could even consider the new
behavior to be consistent with RFC 3280 since it says
in section 6.2:

   [...] the path validation algorithm presented in
   section 6.1 defines the minimum conditions for a
   path to be considered valid.

Prohibiting duplicate certificates is an additional
condition and therefore permitted by RFC 3280.

Steve Hanna

Takashi ITO wrote:
> 
> Hello,
> 
> I have a question about "certification path" in RFC 3280.
> 
> In X.509(4th) "10.1 Path Processing inputs", text says:
> 
>     The inputs to the certification path processing procedure are:
> 
>     a)  a set of certificates comprising a certification path;
>     NOTE - Each certificate in a certification path is unique.
>     A path that contains the same certificate two or more times
>     is not a valid certification path.
> 
>     ...(snip)
> 
> This means, for example, "CA1 -> CA2 -> CA1 -> EE" is not a valid
> certification path.
> 
> In RFC 3280, is this path appropriate for path processing inputs?
> I couldn't find descriptions about this in RFC 3280...
> 
> Could you please give me any comments?
> 
> Thanks,
> 
> Takashi ITO <[email-masked]>
> Mitsubishi Electric Corporation

Date: Thu, 15 May 2003 20:58:18 +0900
From: Takashi ITO <[email-masked]>
Subject: RFC 3280: same certificate in a certification path
To: [email-masked]
Sender: [email-masked]

Hello,

I have a question about "certification path" in RFC 3280.

In X.509(4th) "10.1 Path Processing inputs", text says:

    The inputs to the certification path processing procedure are:

    a)  a set of certificates comprising a certification path;
    NOTE - Each certificate in a certification path is unique.
    A path that contains the same certificate two or more times
    is not a valid certification path.

    ...(snip)

This means, for example, "CA1 -> CA2 -> CA1 -> EE" is not a valid
certification path.

In RFC 3280, is this path appropriate for path processing inputs?
I couldn't find descriptions about this in RFC 3280...

Could you please give me any comments?

Thanks,

Takashi ITO <[email-masked]>
Mitsubishi Electric Corporation

Date: Mon, 12 May 2003 16:13:56 -0700
To: "todd glassey" <[email-masked]>, "el-sign: electronic signatures - open discussion" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: Fw: I want to coin a term if I can... its called "Digital Perjury"...
Cc: "Tina Bird" <[email-masked]>
Sender: [email-masked]

Hi Todd,

(I love definitions and dictionaries)

You might want to be a bit circumspect in the term "Digital Perjury".

If I was in Utah at the time of a given crime, I can lie to my friends and 
say I was in Idaho.  Not perjury, of course.  I can lie to police 
investigators (and be charged with obstruction of justice, aiding and 
abetting, interference with an investigation, etc, but NOT with 
perjury.)  And if, under oath in a court proceeding, I state truthfully 
that I was indeed in Utah, NONE of my previous lies represent perjury.

While I am unfamiliar with the specifics of "digital token under eSign or 
other local/regional ordinance or statute", I have to wonder if every 
instance of fraudulence can be held tantamount to perjury, that each 
instance of (such) signature is to be held equivalent to "an oath taken 
before a court proceeding".

I believe, only fraudulent creation of tokens demanded under subpoena may 
be deemed evidence of perjury.

The mere fact that a lie I tell might eventually become evidence in a legal 
process is (IMHO) insufficient to warrant the term "perjury".

Just my thoughts on the issue.

Cheers!  ____tony____

At 02:45 PM 5/12/2003 -0700, todd glassey wrote:

>Hi there,
>I want to formally add a new term to this organizations vocabulary.  Its
>"Digital Perjury" and we will be working on a formal set of definitions in
>the ISC's Digital Evidence WG.
>
>More coming soon on this.
>
>Todd Glassey
>"technical wordsmith"
>
>----- Original Message -----
>From: "todd glassey" <[email-masked]>
>To: <[email-masked]>
>Sent: Monday, May 12, 2003 1:43 PM
>Subject: I want to coin a term if I can... its called "Digital Perjury"...
>
>
>The Term is Digital Perjury and refers to the fraudulent creation of a
>digital token under eSign or other local/regional ordinance or statute. Or
>the fraudulent submission of a token to certify and act that is constrained
>under the umbrella of the eSign or other DSA legislation.
>
>any other ideas?
>
>Todd
>
>To unsubscribe send the following in the body of a message to
>[email-masked]  - unsubscribe st-isc

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

From: "todd glassey" <[email-masked]>
To: "el-sign: electronic signatures - open discussion" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "Tina Bird" <[email-masked]>
Subject: Fw: I want to coin a term if I can... its called "Digital Perjury"...
Date: Mon, 12 May 2003 14:45:57 -0700
Sender: [email-masked]

Hi there,
I want to formally add a new term to this organizations vocabulary.  Its
"Digital Perjury" and we will be working on a formal set of definitions in
the ISC's Digital Evidence WG.

More coming soon on this.

Todd Glassey
"technical wordsmith"

----- Original Message ----- 
From: "todd glassey" <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 12, 2003 1:43 PM
Subject: I want to coin a term if I can... its called "Digital Perjury"...

The Term is Digital Perjury and refers to the fraudulent creation of a
digital token under eSign or other local/regional ordinance or statute. Or
the fraudulent submission of a token to certify and act that is constrained
under the umbrella of the eSign or other DSA legislation.

any other ideas?

Todd

To unsubscribe send the following in the body of a message to
[email-masked]  - unsubscribe st-isc

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-proxy-06.txt
Date: Mon, 12 May 2003 10:48:11 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Proxy 
                          Certificate Profile
	Author(s)	: S. Tuecke et al.
	Filename	: draft-ietf-pkix-proxy-06.txt
	Pages		: 45
	Date		: 2003-5-9
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 Public Key Infrastructure (PKI) certificates as 
defined in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is derived from, 
and signed by, a normal X.509 Public Key End Entity Certificate or 
by another Proxy Certificate for the purpose of providing 
restricted proxying and delegation within a PKI based 
authentication system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-proxy-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-proxy-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-proxy-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-proxy-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-proxy-06.txt
Date: Mon, 12 May 2003 07:23:49 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Proxy 
                          Certificate Profile
	Author(s)	: S. Tuecke et al.
	Filename	: draft-ietf-pkix-proxy-06.txt
	Pages		: 45
	Date		: 2003-5-9
	
This document forms a certificate profile for Proxy Certificates, 
based on X.509 Public Key Infrastructure (PKI) certificates as 
defined in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is derived from, 
and signed by, a normal X.509 Public Key End Entity Certificate or 
by another Proxy Certificate for the purpose of providing 
restricted proxying and delegation within a PKI based 
authentication system.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-proxy-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-proxy-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-proxy-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-proxy-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 09 May 2003 14:46:12 -0400
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: draft-ietf-pkix-pi-06
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Steve & Tim:

It is clear that an update to the Internet-Draft is needed to resolve the 
DISCUSS votes.  Recent traffic on the PKIX working group mail list indicate 
that there is not an obvious consensus on the correct solutions to the 
issues that have been raised.  Therefore, I am returning the document to 
the working group.

Please let me know when the working group has produced an Internet-Draft 
that has working group consensus and resolves the issues raised in the 
DISCUSS votes.

Russ 

From: "Von Welch" <[email-masked]>
Date: Fri, 9 May 2003 10:11:23 -0500
To: <[email-masked]>
Cc: "'IETF-PKIX'" <[email-masked]>
Subject: RE: Proxy -05 comments
Sender: [email-masked]

Jim,

 Our emails crossed last night, but I'm still holding my opinion that
while I think you may be right in that we could allow this behavior,
I'm concerned about making this change for two reasons: 1) encoding
this will be difficult - you now have to look ahead to figure out if a
failure to understand a policy language is critical or not and 2) this
change seems risky due to lack of thought about it and it potentially
opens holes in the current model which I see as being safer since it
fails on any unrecognized policy language.

 So I would like to deferr considering this change until a future
specification when we've had more experience and time to think about
it unless you think it's absolutely critical.

 I'm going to go ahead and push a new version of the draft today with
the minor corrections from the last week.

Von

Jim Schaad writes (20:03 May 8, 2003):
 > 
 > 
 > > -----Original Message-----
 > > From: [email-masked] 
 > > [mailto:[email-masked]] On Behalf Of Von Welch
 > > Sent: Thursday, May 08, 2003 11:41 AM
 > > To: [email-masked]
 > > Cc: 'IETF-PKIX'
 > > Subject: RE: Proxy -05 comments
 > > 
 > > 
 > > 
 > > Jim Schaad writes (10:15 May 8, 2003):
 > >  > >  > 4)  If I have the following chain of certificates, please 
 > >  > > explain why it  > should be rejected  > 
 > >  > >  > 	EE	subject="cn=me"
 > >  > >  > 	PC1	subject="cn=me,cn=1"  Policy=id-pp-inheritall
 > >  > >  > 	PC2	subject="cn=me,cn=1,cn=1" Policy=MySpecialPolicy
 > >  > >  > 	PC3	subject="cn=me,cn=1,cn=1,cn=1" 
 > > Policy=id-pp-independent
 > >  > >  > 
 > >  > >  > If I set acceptable-pc-policy-set to "inheritall, 
 > >  > > independent" this get  > rejected, but the evaluation code 
 > >  > > would seem to be fine in terms of  > evaluating this policy 
 > >  > > as MySpecialPolicy does not get involved in  > making any 
 > >  > > proxy decisions for PC3.  It's proxy rights are independent  
 > >  > > > of any previous statements.
 > >  > > 
 > >  > > The intent was to allow for conditions of use to be expressed 
 > >  > > in policies that would be unsafe to ignore. For example, a 
 > >  > > policy could state that a relying party must check a CRL at 
 > >  > > http://xxxxx before using the proxy. However, reviewing 3.8.2 
 > >  > > I see that we never about this and I can see your point 
 > > of view.  > > 
 > >  > > I believe what you are suggesting is that any unrecognized 
 > >  > > policy should be treated as id-ppl-independent?
 > >  > > 
 > >  > > Let me run this by a coauthor or two and get back to you.  > 
 > >  > I wasn't really thinking that the PC2 policy was the same 
 > > as  > independent, just the fact that it's not relevent as 
 > > all inherited  > rights (from policy) are now ignored by the 
 > > independent.
 > > 
 > > Imagine your chain above ended with PC2 and you didn't 
 > > recognize it's policy language. In terms of processing, when 
 > > an unrecognized policy language is encountered the two 
 > > choices would be to either fail or proceed and treat PC2 as 
 > > independant (no rights inherited from PC1).
 > 
 > I agree in this case there would be a failure at the time of evaluation
 > for rights.  I don't believe in the case listed above that I need to do
 > any evaluation of the rights for PC2 if PC3 exists. 
 > 
 > > 
 > >  > >  > 4.  I don't like this sentence for independent.
 > >  > >  > 
 > >  > >  >        The only rights this PC has are those granted 
 > >  > > explicitly to it. 
 > >  > >  > 
 > >  > >  > 	I suggest
 > >  > >  > 
 > >  > >  > 	The only rights the holder of this PC has are 
 > > those explicitly
 > >  > >  > granted by other  means than the proxy certificate.
 > >  > > 
 > >  > > But this isn't technically correct as there could be rights 
 > >  > > granted directly to the identity in the PC.
 > >  > 
 > >  > I don't see the difference between these staements.  The 
 > > holder of the  > PC has an identity, rights granted directly 
 > > to that are done by means  > other than the proxy certificate.
 > > 
 > > Your wording leads me to believe the PC is ignored entirely - 
 > > the only rights are those "granted by other means than the 
 > > proxy certificate". This to me includes the PC identity as 
 > > well as inherited rights.
 > > 
 > > How about the following?
 > > 
 > > <quote>
 > > The only rights the holder of this PC has are those granted 
 > > by means other than inheritance from it's proxy issuer (e.g. 
 > > rights issued directly to the identity in the proxy 
 > > certificate). </quote>
 > 
 > I have no problems with this text.
 > 
 > > 
 > > Von
 > > 
 > > 
 > > 
 > >  > > 
 > >  > > -end-
 > >  > > 
 > >  > 
 > >  > Jim
 > >  > 
 > > 
 > 

To: Denis Pinkas <[email-masked]>
Cc: Russ Housley <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-pi
From: Tom Gindin <[email-masked]>
Date: Fri, 9 May 2003 00:04:59 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 00166B2485256D21_=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

        I would oppose deleting the URI option, for two basic reasons:
1       A URI dependent on a domain name is no more impermanent than many=20
other certificate fields, including such SubjectAltName fields as IP=20
address, DNS name, and rfc822Name.
2       The procedure to locate the owner of an OID cannot feasibly be=20
automated.  This would matter less if the OID were a user-friendly name=20
from which the owning organization could be guessed by a human RP, but it=20
is not.

                Tom Gindin

Denis Pinkas <[email-masked]>
Sent by: [email-masked]
05/07/2003 02:24 PM

=20
        To:     Russ Housley <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: draft-ietf-pkix-pi

Russ,

> Mike:
>=20
> No.  At this point, we are asking questions.
>=20
> Russ
>=20
> At 05:46 PM 4/25/2003 -0700, Michael Myers wrote:
>=20
>> >
>> >IdentifierType ::=3D CHOICE {
>> >    registeredOID         OBJECT IDENTIFIER,
>> >    uri                   IA5String }

The text says:

    The IdentifierType field may contain a registeredOID in the form of :

            a) an Object Identifier (i.e. an OID), or
            b) a *permanent* URI using IA5String.

    Characteristically, when an OID is used, the prefix of the OID
    identifies the organization, and a suffix is used to identify the
    type of permanent identifier being identified.  Essentially the
    same thing is true of URI's.

In fact, the same thing is not fully true for URIs. This is only true if=20
the=20
URI is *permanent* and the only URI that currently has that=20
characteristics=20
is: www.w3.org.

I have had many discussions on that topic with Tom, but personnaly, since=20
The IESG asked the question, I would delete uri and keep only=20
registeredOID,=20
since the concept of permanent URIs does not exist (if a URI is not paid=20
during some period of time, it may be sold to another organisation).

W3C in its statutes mentions that it will pay for ever to keep that URI.=20
Since some "old" organisations like the MIT are part of W3C, it is likely=20
that some money will be available to pay for that URI still for a long=20
time.

Currently, W3C is only willing to provider URIs under its own URI for=20
companies/organisations that are members of W3C.

Denis

>>
>> Russ,
>>
>> Please clarify.  Is the IESG saying the WG MUST eliminate the
>> CHOICE and so select a single type?
>>
>> Mike
>=20
>=20
>=20

--=_alternative 00166B2485256D21_=
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<br><font size=3D2 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; I would =
oppose deleting the URI option, for two basic reasons:</font>
<br><font size=3D2 face=3D"sans-serif">1 &nbsp; &nbsp; &nbsp; &nbsp;A URI d=
ependent on a domain name is no more impermanent than many other certificat=
e fields, including such SubjectAltName fields as IP address, DNS name, and=
 rfc822Name.</font>
<br><font size=3D2 face=3D"sans-serif">2 &nbsp; &nbsp; &nbsp; &nbsp;The pro=
cedure to locate the owner of an OID cannot feasibly be automated. &nbsp;Th=
is would matter less if the OID were a user-friendly name from which the ow=
ning organization could be guessed by a human RP, but it is not.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Tom Gindin<br>
<br>
</font>
<br>
<br>
<br>
<table width=3D100%>
<tr valign=3Dtop>
<td>
<td><font size=3D1 face=3D"sans-serif"><b>Denis Pinkas &lt;Denis.Pinkas@bul=
l.net&gt;</b></font>
<br><font size=3D1 face=3D"sans-serif">Sent by: [email-masked]=
g</font>
<p><font size=3D1 face=3D"sans-serif">05/07/2003 02:24 PM</font>
<br>
<td><font size=3D1 face=3D"Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbs=
p; &nbsp; &nbsp; &nbsp;Russ Housley &lt;[email-masked]&gt;</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbs=
p; &nbsp; &nbsp; &nbsp;[email-masked]</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:=
 &nbsp; &nbsp; &nbsp; &nbsp;Re: draft-ietf-pkix-pi</font>
<br></table>
<br>
<br>
<br><font size=3D2 face=3D"Courier New"><br>
Russ,<br>
<br>
&gt; Mike:<br>
&gt; <br>
&gt; No. &nbsp;At this point, we are asking questions.<br>
&gt; <br>
&gt; Russ<br>
&gt; <br>
&gt; At 05:46 PM 4/25/2003 -0700, Michael Myers wrote:<br>
&gt; <br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;IdentifierType ::=3D CHOICE {<br>
&gt;&gt; &gt; &nbsp; &nbsp;registeredOID &nbsp; &nbsp; &nbsp; &nbsp; OBJECT=
 IDENTIFIER,<br>
&gt;&gt; &gt; &nbsp; &nbsp;uri &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; IA5String }<br>
<br>
The text says:<br>
<br>
 &nbsp; &nbsp;The IdentifierType field may contain a registeredOID in the f=
orm of :<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;a) an Object Identifier (i.e. an =
OID), or<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;b) a *permanent* URI using IA5Str=
ing.<br>
<br>
 &nbsp; &nbsp;Characteristically, when an OID is used, the prefix of the OI=
D<br>
 &nbsp; &nbsp;identifies the organization, and a suffix is used to identify=
 the<br>
 &nbsp; &nbsp;type of permanent identifier being identified. &nbsp;Essentia=
lly the<br>
 &nbsp; &nbsp;same thing is true of URI's.<br>
<br>
In fact, the same thing is not fully true for URIs. This is only true if th=
e <br>
URI is *permanent* and the only URI that currently has that characteristics=
 <br>
is: www.w3.org.<br>
<br>
I have had many discussions on that topic with Tom, but personnaly, since <=
br>
The IESG asked the question, I would delete uri and keep only registeredOID=
, <br>
since the concept of permanent URIs does not exist (if a URI is not paid <b=
r>
during some period of time, it may be sold to another organisation).<br>
<br>
W3C in its statutes mentions that it will pay for ever to keep that URI. <b=
r>
Since some &quot;old&quot; organisations like the MIT are part of W3C, it i=
s likely <br>
that some money will be available to pay for that URI still for a long time=
.<br>
<br>
Currently, W3C is only willing to provider URIs under its own URI for <br>
companies/organisations that are members of W3C.<br>
<br>
Denis<br>
<br>
&gt;&gt;<br>
&gt;&gt; Russ,<br>
&gt;&gt;<br>
&gt;&gt; Please clarify. &nbsp;Is the IESG saying the WG MUST eliminate the=
<br>
&gt;&gt; CHOICE and so select a single type?<br>
&gt;&gt;<br>
&gt;&gt; Mike<br>
&gt; <br>
&gt; <br>
&gt; <br>
<br>
<br>
<br>
</font>
<br>
<br>
--=_alternative 00166B2485256D21_=--

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Laura Pearlman'" <[email-masked]>, "'Von Welch'" <[email-masked]>
Cc: <[email-masked]>, "'IETF-PKIX'" <[email-masked]>
Subject: RE: Proxy -05 comments 
Date: Thu, 8 May 2003 20:07:33 -0700
Importance: Normal
Sender: [email-masked]

Laura,

Now you are changning the meaning of this.  The Policy Language gives
rights, not additional items to be enforced.  The only right that is of
interest here is the right to issue a PC, which is controled by a
different field here (I don't have the name in front of me at the
moment).

Things like CRLs should be dealt with by advertising them, not by adding
other things that say you need to check a CRL before using this.
Remember that policy is evaluated by a completely different piece of
code that the chain evaluation code.  Thus the two should not mix for
purposes of standards.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Laura Pearlman
> Sent: Thursday, May 08, 2003 3:21 PM
> To: Von Welch
> Cc: [email-masked]; 'IETF-PKIX'
> Subject: Re: Proxy -05 comments 
> 
> 
> 
> Von Welch writes:
> >
> > Jim Schaad writes (10:15 May 8, 2003):
> >  > >  > 4)  If I have the following chain of certificates, please
> >  > > explain why it  > should be rejected  > 
> >  > >  > 	EE	subject="cn=me"
> >  > >  > 	PC1	subject="cn=me,cn=1"  Policy=id-pp-inheritall
> >  > >  > 	PC2	subject="cn=me,cn=1,cn=1" Policy=MySpecialPolicy
> >  > >  > 	PC3	subject="cn=me,cn=1,cn=1,cn=1" 
> Policy=id-pp-independent
> >  > >  > 
> >  > >  > If I set acceptable-pc-policy-set to "inheritall, 
> >  > > independent" this get  > rejected, but the evaluation code 
> >  > > would seem to be fine in terms of  > evaluating this policy 
> >  > > as MySpecialPolicy does not get involved in  > making any 
> >  > > proxy decisions for PC3.  It's proxy rights are independent  
> >  > > > of any previous statements.
> >  > > 
> >  > > The intent was to allow for conditions of use to be expressed 
> >  > > in policies that would be unsafe to ignore. For example, a 
> >  > > policy could state that a relying party must check a CRL at 
> >  > > http://xxxxx before using the proxy. However, reviewing 3.8.2 
> >  > > I see that we never about this and I can see your 
> point of view.
> >  > > 
> >  > > I believe what you are suggesting is that any unrecognized 
> >  > > policy should be treated as id-ppl-independent?
> >  > > 
> >  > > Let me run this by a coauthor or two and get back to you.
> >  > 
> >  > I wasn't really thinking that the PC2 policy was the same as
> >  > independent, just the fact that it's not relevent as all 
> inherited
> >  > rights (from policy) are now ignored by the independent.
> > 
> > Imagine your chain above ended with PC2 and you didn't 
> recognize it's 
> > policy language. In terms of processing, when an 
> unrecognized policy 
> > language is encountered the two choices would be to either fail or 
> > proceed and treat PC2 as independant (no rights inherited from PC1).
> 
> I think that the proxy processing should support policies 
> that are intended to prevent the use of compromised 
> certificates (for example, policies that enforce certificate 
> revocation mechanisms or that say that a proxy certificate is 
> valid only from one host).  If MySpecialPolicy in the example 
> above is such a policy, and a relying party ignores it while 
> evaluating PC3, then the danger is that PC2 may have been 
> compromised, and some third party may have used the 
> compromised PC2 to create an independent proxy (PC3') with 
> the same subject name as PC3.  Even though PC3 itself does 
> not grant any rights to its bearer, it's possible (and 
> likely) that additional rights will have been granted to PC3 
> via some external mechanism -- which means that if 
> MySpecialPolicy is ignored, then a third party can use PC3' 
> to gain whatever rights have been (externally) granted to the 
> holder of PC3.
> 
> So I think there are two reasonable alternatives:  either 
> always fail when an unrecognized policy is encountered, or 
> change ProxyPolicy to include the concept of critical and 
> non-critical policies.
> 
> 		-- Laura
> 

From: "Von Welch" <[email-masked]>
Date: Thu, 8 May 2003 22:05:40 -0500
To: Laura Pearlman <[email-masked]>
Cc: [email-masked], "'IETF-PKIX'" <[email-masked]>
Subject: Re: Proxy -05 comments 
Sender: [email-masked]

Laura, Jim:

 While I see both your points (critical/non-critical policies and
being able to ignore unrecognized policie languages in certain
situations), I'm inclined for the sake of simplicity to stick with a
relying party failing if a unrecognized policy language is found. This
leaves the door open for the possibility of "conditions of use"
polcies in the future.

 It also seems safer to me in that we really haven't thought through
all the subtleties of loosing the restriction, so I'd prefer not to at
this point in the game unless one of you feels has a strong use case.

Von

Laura Pearlman writes (15:20 May 8, 2003):
 > Von Welch writes:
 > >
 > > Jim Schaad writes (10:15 May 8, 2003):
 > >  > >  > 4)  If I have the following chain of certificates, please 
 > >  > > explain why it  > should be rejected  > 
 > >  > >  > 	EE	subject="cn=me"
 > >  > >  > 	PC1	subject="cn=me,cn=1"  Policy=id-pp-inheritall
 > >  > >  > 	PC2	subject="cn=me,cn=1,cn=1" Policy=MySpecialPolicy
 > >  > >  > 	PC3	subject="cn=me,cn=1,cn=1,cn=1" Policy=id-pp-independent
 > >  > >  > 
 > >  > >  > If I set acceptable-pc-policy-set to "inheritall, 
 > >  > > independent" this get  > rejected, but the evaluation code 
 > >  > > would seem to be fine in terms of  > evaluating this policy 
 > >  > > as MySpecialPolicy does not get involved in  > making any 
 > >  > > proxy decisions for PC3.  It's proxy rights are independent  
 > >  > > > of any previous statements.
 > >  > > 
 > >  > > The intent was to allow for conditions of use to be expressed 
 > >  > > in policies that would be unsafe to ignore. For example, a 
 > >  > > policy could state that a relying party must check a CRL at 
 > >  > > http://xxxxx before using the proxy. However, reviewing 3.8.2 
 > >  > > I see that we never about this and I can see your point of view.
 > >  > > 
 > >  > > I believe what you are suggesting is that any unrecognized 
 > >  > > policy should be treated as id-ppl-independent?
 > >  > > 
 > >  > > Let me run this by a coauthor or two and get back to you.
 > >  > 
 > >  > I wasn't really thinking that the PC2 policy was the same as
 > >  > independent, just the fact that it's not relevent as all inherited
 > >  > rights (from policy) are now ignored by the independent.
 > > 
 > > Imagine your chain above ended with PC2 and you didn't recognize it's
 > > policy language. In terms of processing, when an unrecognized policy
 > > language is encountered the two choices would be to either fail or
 > > proceed and treat PC2 as independant (no rights inherited from PC1).
 > 
 > I think that the proxy processing should support policies that are
 > intended to prevent the use of compromised certificates (for example,
 > policies that enforce certificate revocation mechanisms or that say
 > that a proxy certificate is valid only from one host).  If
 > MySpecialPolicy in the example above is such a policy, and a relying
 > party ignores it while evaluating PC3, then the danger is that PC2 may
 > have been compromised, and some third party may have used the
 > compromised PC2 to create an independent proxy (PC3') with the same
 > subject name as PC3.  Even though PC3 itself does not grant any rights
 > to its bearer, it's possible (and likely) that additional rights will
 > have been granted to PC3 via some external mechanism -- which means
 > that if MySpecialPolicy is ignored, then a third party can use PC3' to
 > gain whatever rights have been (externally) granted to the holder of
 > PC3.
 > 
 > So I think there are two reasonable alternatives:  either always fail
 > when an unrecognized policy is encountered, or change ProxyPolicy
 > to include the concept of critical and non-critical policies.
 > 
 > 		-- Laura
 > 

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Von Welch'" <[email-masked]>, <[email-masked]>
Cc: "'IETF-PKIX'" <[email-masked]>
Subject: RE: Proxy -05 comments
Date: Thu, 8 May 2003 20:03:52 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Von Welch
> Sent: Thursday, May 08, 2003 11:41 AM
> To: [email-masked]
> Cc: 'IETF-PKIX'
> Subject: RE: Proxy -05 comments
> 
> 
> 
> Jim Schaad writes (10:15 May 8, 2003):
>  > >  > 4)  If I have the following chain of certificates, please 
>  > > explain why it  > should be rejected  > 
>  > >  > 	EE	subject="cn=me"
>  > >  > 	PC1	subject="cn=me,cn=1"  Policy=id-pp-inheritall
>  > >  > 	PC2	subject="cn=me,cn=1,cn=1" Policy=MySpecialPolicy
>  > >  > 	PC3	subject="cn=me,cn=1,cn=1,cn=1" 
> Policy=id-pp-independent
>  > >  > 
>  > >  > If I set acceptable-pc-policy-set to "inheritall, 
>  > > independent" this get  > rejected, but the evaluation code 
>  > > would seem to be fine in terms of  > evaluating this policy 
>  > > as MySpecialPolicy does not get involved in  > making any 
>  > > proxy decisions for PC3.  It's proxy rights are independent  
>  > > > of any previous statements.
>  > > 
>  > > The intent was to allow for conditions of use to be expressed 
>  > > in policies that would be unsafe to ignore. For example, a 
>  > > policy could state that a relying party must check a CRL at 
>  > > http://xxxxx before using the proxy. However, reviewing 3.8.2 
>  > > I see that we never about this and I can see your point 
> of view.  > > 
>  > > I believe what you are suggesting is that any unrecognized 
>  > > policy should be treated as id-ppl-independent?
>  > > 
>  > > Let me run this by a coauthor or two and get back to you.  > 
>  > I wasn't really thinking that the PC2 policy was the same 
> as  > independent, just the fact that it's not relevent as 
> all inherited  > rights (from policy) are now ignored by the 
> independent.
> 
> Imagine your chain above ended with PC2 and you didn't 
> recognize it's policy language. In terms of processing, when 
> an unrecognized policy language is encountered the two 
> choices would be to either fail or proceed and treat PC2 as 
> independant (no rights inherited from PC1).

I agree in this case there would be a failure at the time of evaluation
for rights.  I don't believe in the case listed above that I need to do
any evaluation of the rights for PC2 if PC3 exists. 

> 
>  > >  > 4.  I don't like this sentence for independent.
>  > >  > 
>  > >  >        The only rights this PC has are those granted 
>  > > explicitly to it. 
>  > >  > 
>  > >  > 	I suggest
>  > >  > 
>  > >  > 	The only rights the holder of this PC has are 
> those explicitly
>  > >  > granted by other  means than the proxy certificate.
>  > > 
>  > > But this isn't technically correct as there could be rights 
>  > > granted directly to the identity in the PC.
>  > 
>  > I don't see the difference between these staements.  The 
> holder of the  > PC has an identity, rights granted directly 
> to that are done by means  > other than the proxy certificate.
> 
> Your wording leads me to believe the PC is ignored entirely - 
> the only rights are those "granted by other means than the 
> proxy certificate". This to me includes the PC identity as 
> well as inherited rights.
> 
> How about the following?
> 
> <quote>
> The only rights the holder of this PC has are those granted 
> by means other than inheritance from it's proxy issuer (e.g. 
> rights issued directly to the identity in the proxy 
> certificate). </quote>

I have no problems with this text.

> Von
>  > > -end-
>  > Jim

To: "Von Welch" <[email-masked]>
cc: [email-masked], "'IETF-PKIX'" <[email-masked]>
Subject: Re: Proxy -05 comments 
Date: Thu, 08 May 2003 15:20:51 -0700
From: Laura Pearlman <[email-masked]>
Sender: [email-masked]

Von Welch writes:
>
> Jim Schaad writes (10:15 May 8, 2003):
>  > >  > 4)  If I have the following chain of certificates, please 
>  > > explain why it  > should be rejected  > 
>  > >  > 	EE	subject="cn=me"
>  > >  > 	PC1	subject="cn=me,cn=1"  Policy=id-pp-inheritall
>  > >  > 	PC2	subject="cn=me,cn=1,cn=1" Policy=MySpecialPolicy
>  > >  > 	PC3	subject="cn=me,cn=1,cn=1,cn=1" Policy=id-pp-independent
>  > >  > 
>  > >  > If I set acceptable-pc-policy-set to "inheritall, 
>  > > independent" this get  > rejected, but the evaluation code 
>  > > would seem to be fine in terms of  > evaluating this policy 
>  > > as MySpecialPolicy does not get involved in  > making any 
>  > > proxy decisions for PC3.  It's proxy rights are independent  
>  > > > of any previous statements.
>  > > 
>  > > The intent was to allow for conditions of use to be expressed 
>  > > in policies that would be unsafe to ignore. For example, a 
>  > > policy could state that a relying party must check a CRL at 
>  > > http://xxxxx before using the proxy. However, reviewing 3.8.2 
>  > > I see that we never about this and I can see your point of view.
>  > > 
>  > > I believe what you are suggesting is that any unrecognized 
>  > > policy should be treated as id-ppl-independent?
>  > > 
>  > > Let me run this by a coauthor or two and get back to you.
>  > 
>  > I wasn't really thinking that the PC2 policy was the same as
>  > independent, just the fact that it's not relevent as all inherited
>  > rights (from policy) are now ignored by the independent.
> 
> Imagine your chain above ended with PC2 and you didn't recognize it's
> policy language. In terms of processing, when an unrecognized policy
> language is encountered the two choices would be to either fail or
> proceed and treat PC2 as independant (no rights inherited from PC1).

I think that the proxy processing should support policies that are
intended to prevent the use of compromised certificates (for example,
policies that enforce certificate revocation mechanisms or that say
that a proxy certificate is valid only from one host).  If
MySpecialPolicy in the example above is such a policy, and a relying
party ignores it while evaluating PC3, then the danger is that PC2 may
have been compromised, and some third party may have used the
compromised PC2 to create an independent proxy (PC3') with the same
subject name as PC3.  Even though PC3 itself does not grant any rights
to its bearer, it's possible (and likely) that additional rights will
have been granted to PC3 via some external mechanism -- which means
that if MySpecialPolicy is ignored, then a third party can use PC3' to
gain whatever rights have been (externally) granted to the holder of
PC3.

So I think there are two reasonable alternatives:  either always fail
when an unrecognized policy is encountered, or change ProxyPolicy
to include the concept of critical and non-critical policies.

		-- Laura

From: "Von Welch" <[email-masked]>
Date: Thu, 8 May 2003 13:40:30 -0500
To: <[email-masked]>
Cc: "'IETF-PKIX'" <[email-masked]>
Subject: RE: Proxy -05 comments
Sender: [email-masked]

Jim Schaad writes (10:15 May 8, 2003):
 > >  > 4)  If I have the following chain of certificates, please 
 > > explain why it  > should be rejected  > 
 > >  > 	EE	subject="cn=me"
 > >  > 	PC1	subject="cn=me,cn=1"  Policy=id-pp-inheritall
 > >  > 	PC2	subject="cn=me,cn=1,cn=1" Policy=MySpecialPolicy
 > >  > 	PC3	subject="cn=me,cn=1,cn=1,cn=1" Policy=id-pp-independent
 > >  > 
 > >  > If I set acceptable-pc-policy-set to "inheritall, 
 > > independent" this get  > rejected, but the evaluation code 
 > > would seem to be fine in terms of  > evaluating this policy 
 > > as MySpecialPolicy does not get involved in  > making any 
 > > proxy decisions for PC3.  It's proxy rights are independent  
 > > > of any previous statements.
 > > 
 > > The intent was to allow for conditions of use to be expressed 
 > > in policies that would be unsafe to ignore. For example, a 
 > > policy could state that a relying party must check a CRL at 
 > > http://xxxxx before using the proxy. However, reviewing 3.8.2 
 > > I see that we never about this and I can see your point of view.
 > > 
 > > I believe what you are suggesting is that any unrecognized 
 > > policy should be treated as id-ppl-independent?
 > > 
 > > Let me run this by a coauthor or two and get back to you.
 > 
 > I wasn't really thinking that the PC2 policy was the same as
 > independent, just the fact that it's not relevent as all inherited
 > rights (from policy) are now ignored by the independent.

Imagine your chain above ended with PC2 and you didn't recognize it's
policy language. In terms of processing, when an unrecognized policy
language is encountered the two choices would be to either fail or
proceed and treat PC2 as independant (no rights inherited from PC1).

 > >  > 4.  I don't like this sentence for independent.
 > >  > 
 > >  >        The only rights this PC has are those granted 
 > > explicitly to it. 
 > >  > 
 > >  > 	I suggest
 > >  > 
 > >  > 	The only rights the holder of this PC has are those explicitly
 > >  > granted by other  means than the proxy certificate.
 > > 
 > > But this isn't technically correct as there could be rights 
 > > granted directly to the identity in the PC.
 > 
 > I don't see the difference between these staements.  The holder of the
 > PC has an identity, rights granted directly to that are done by means
 > other than the proxy certificate.

Your wording leads me to believe the PC is ignored entirely - the
only rights are those "granted by other means than the proxy
certificate". This to me includes the PC identity as well as inherited
rights.

How about the following?

<quote>
The only rights the holder of this PC has are those granted by means
other than inheritance from it's proxy issuer (e.g. rights issued
directly to the identity in the proxy certificate).
</quote>

Von

 > > -end-
 > Jim

Date: Thu, 08 May 2003 19:40:53 +0200
From: Jean-Marc Desperrier <[email-masked]>
Organization: totalement desorganise
To: [email-masked]
Subject: Re: time stamp of a CMS with multiple signatures
Sender: [email-masked]

Miguel Rodriguez wrote:

>In TSP (RFC 3161) appendix A there's a guideline on how to store a time
>stamp in a CMS, and it says that the messageImprint shall be the hash of
>the signature field within the SignerInfo  for the SignedData being
>timestamped. What should be the messageImprint for a SignedData with
>multiple SignerInfo fields?
>
As it is described in appendix A, the timestamp will be the timestamp of 
a single signature, more than the timestamp of a document.

If you have multiple SignerInfo and stick to RFC3161, you will need 
multiple time-stamps.

If I haven't missed something, RFC3126 does not provide a solution to 
use only one signature in this case, but suggests to used embedded 
signature (embedding each signed CMS inside another signed CMS) instead 
of independent signatures (multiple SignerInfo) if you want to use only 
one time-stamp.

As anyway the time-stamp you want will only be added after the fact, 
after each independent signature has been added, you could embed the 
document inside a CMS signed by yourself, and timestamp this CMS.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Von Welch'" <[email-masked]>
Cc: "'IETF-PKIX'" <[email-masked]>
Subject: RE: Proxy -05 comments
Date: Thu, 8 May 2003 10:15:09 -0700
Importance: Normal
Sender: [email-masked]

Von,
> 
> Jim,
> 
> Responses and questions below.
> 
> Thanks,
> 
> Von
> 
> Jim Schaad writes (00:00 May 4, 2003):
>  > 
>  > 
>  > 
>  > Comments are divided into two sections, those of substance 
> and  > nit-picking.  > 
>  > Substance:
>  > 
>  > 2) The following text:
>  >     *  InheritAll, as defined by the oid value iso(1) identified-
>  >        organization(3) dod(6) internet(1) security(5) 
> mechanisms(5) 
>  >        pkix(7) ppl(21) inheritall(1)
>  > 
>  > 	says that the ASN.1 module needs the following change
>  > 
>  >  id-ppl-inheritall           OBJECT IDENTIFIER ::= { id-ppl 1 } 
>  > 	
>  > 	to
>  > 
>  >  id-ppl-inheritall           OBJECT IDENTIFIER ::= { id-ppl
>  > inheritall(1) } 
> 
> I'll admit I'm past my level of ASN.1 knowledge here. Is 
> there a semantic difference between what I have and what you 
> are suggesting or is this syntax for the compiler? My concern 
> here is what is there is what I was assigned, if what you are 
> suggesting is equivalent I have no problem with it and will change it.

No they are not the exactly the same, but this is what the is in the
body of the text.  An alternate is to change the text to 

id-pp-inheritall ::= .... 

But the text in the body and the text in ASN.1 module need to match.

> 
>  > 3)  The following text:
>  >     *  Independent, as defined by the oid value iso(1) identified-
>  >        organization(3) dod(6) internet(1) security(5) 
> mechanisms(5) 
>  >        pkix(7) ppl(21) independent(2)
>  > 
>  > 	says that the ASN.1 module needs the following change
>  > 
>  >  id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl 2 } 
>  > 
>  > 	to
>  > 
>  >  id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl 
> independent(2) } 
> 
> Ditto response to #2.
> 
>  > 4)  If I have the following chain of certificates, please 
> explain why it  > should be rejected  > 
>  > 	EE	subject="cn=me"
>  > 	PC1	subject="cn=me,cn=1"  Policy=id-pp-inheritall
>  > 	PC2	subject="cn=me,cn=1,cn=1" Policy=MySpecialPolicy
>  > 	PC3	subject="cn=me,cn=1,cn=1,cn=1" Policy=id-pp-independent
>  > 
>  > If I set acceptable-pc-policy-set to "inheritall, 
> independent" this get  > rejected, but the evaluation code 
> would seem to be fine in terms of  > evaluating this policy 
> as MySpecialPolicy does not get involved in  > making any 
> proxy decisions for PC3.  It's proxy rights are independent  
> > of any previous statements.
> 
> The intent was to allow for conditions of use to be expressed 
> in policies that would be unsafe to ignore. For example, a 
> policy could state that a relying party must check a CRL at 
> http://xxxxx before using the proxy. However, reviewing 3.8.2 
> I see that we never about this and I can see your point of view.
> 
> I believe what you are suggesting is that any unrecognized 
> policy should be treated as id-ppl-independent?
> 
> Let me run this by a coauthor or two and get back to you.

I wasn't really thinking that the PC2 policy was the same as
independent, just the fact that it's not relevent as all inherited
rights (from policy) are now ignored by the independent.

> 
>  > Nits:
>  > 
>  > 3.  inheritAll and Independent oid definitions in the text.
> 
> Agreed. I've removed the definitions in the text and added a 
> reference to Appendix A.

This takes care of problems 2 and 3 above.

> 
>  > 4.  I don't like this sentence for independent.
>  > 
>  >        The only rights this PC has are those granted 
> explicitly to it. 
>  > 
>  > 	I suggest
>  > 
>  > 	The only rights the holder of this PC has are those explicitly
>  > granted by other  means than the proxy certificate.
> 
> But this isn't technically correct as there could be rights 
> granted directly to the identity in the PC.

I don't see the difference between these staements.  The holder of the
PC has an identity, rights granted directly to that are done by means
other than the proxy certificate.

> -end-

Jim

From: "Von Welch" <[email-masked]>
Date: Wed, 7 May 2003 15:38:54 -0500
To: <[email-masked]>
Cc: "'IETF-PKIX'" <[email-masked]>
Subject: Re: Proxy -05 comments
Sender: [email-masked]

Jim,

Responses and questions below.

Thanks,

Von

Jim Schaad writes (00:00 May 4, 2003):
 > 
 > 
 > 
 > Comments are divided into two sections, those of substance and
 > nit-picking.
 > 
 > Substance:
 > 
 > 1.  I still get confused because of the language used between PKC policy
 > and PC policy.  To clarify this I would like to see the following items
 > changed:
 > 
 > A) change acceptable-pc-policy-set to acceptable-pc-policy-language-set

Done.

 > B) change any-policy to any-policy-language and assign an OID for this

In keeping with the naming for other policy language OIDs I changed
the name to id-ppl-anyLanguage and got an OID for it.

 > C) in 4.1.3 (c) the discription of the tuple is harder than it needs to
 > be.  "containing the certificate subject name, proxyPolicy, key usage
 > extension..."

Changed.

 > 2) The following text:
 >     *  InheritAll, as defined by the oid value iso(1) identified-
 >        organization(3) dod(6) internet(1) security(5) mechanisms(5) 
 >        pkix(7) ppl(21) inheritall(1)
 > 
 > 	says that the ASN.1 module needs the following change
 > 
 >  id-ppl-inheritall           OBJECT IDENTIFIER ::= { id-ppl 1 } 
 > 	
 > 	to
 > 
 >  id-ppl-inheritall           OBJECT IDENTIFIER ::= { id-ppl
 > inheritall(1) } 

I'll admit I'm past my level of ASN.1 knowledge here. Is there a
semantic difference between what I have and what you are suggesting or
is this syntax for the compiler? My concern here is what is there is
what I was assigned, if what you are suggesting is equivalent I have
no problem with it and will change it.

 > 3)  The following text:
 >     *  Independent, as defined by the oid value iso(1) identified-
 >        organization(3) dod(6) internet(1) security(5) mechanisms(5) 
 >        pkix(7) ppl(21) independent(2)
 > 
 > 	says that the ASN.1 module needs the following change
 > 
 >  id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl 2 } 
 > 
 > 	to
 > 
 >  id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl independent(2) } 

Ditto response to #2.

 > 4)  If I have the following chain of certificates, please explain why it
 > should be rejected
 > 
 > 	EE	subject="cn=me"
 > 	PC1	subject="cn=me,cn=1"  Policy=id-pp-inheritall
 > 	PC2	subject="cn=me,cn=1,cn=1" Policy=MySpecialPolicy
 > 	PC3	subject="cn=me,cn=1,cn=1,cn=1" Policy=id-pp-independent
 > 
 > If I set acceptable-pc-policy-set to "inheritall, independent" this get
 > rejected, but the evaluation code would seem to be fine in terms of
 > evaluating this policy as MySpecialPolicy does not get involved in
 > making any proxy decisions for PC3.  It's proxy rights are independent
 > of any previous statements.

The intent was to allow for conditions of use to be expressed in
policies that would be unsafe to ignore. For example, a policy could
state that a relying party must check a CRL at http://xxxxx before
using the proxy. However, reviewing 3.8.2 I see that we never about
this and I can see your point of view.

I believe what you are suggesting is that any unrecognized policy
should be treated as id-ppl-independent?

Let me run this by a coauthor or two and get back to you.

 > Nits:
 > 
 > 1.  Certificates don't issue anything, holders of certificates issue
 > things.  In section 2.1 I suggest the following text:
 > 
 >   * PI: A "Proxy Issuer" is an entity with an End Entity Certificate or
 > a Proxy Certificate that issues a Proxy Certificates.

True enough. I added a little text here to keep the relationship we
were trying to express:

* PI: A "Proxy Issuer" is an entity with an End Entity Certificate or
Proxy Certificate that issues a Proxy Certificate. The Proxy
Certificate is signed using the private key associated with the public
key in the Proxy Issuer's certificate.

 > 2.  Sec 3.8 - second to last paragarph.  MUST NOT rather than MUST not
 > --- alt. MUST be absent.

Corrected to "MUST be absent".

 > 3.  inheritAll and Independent oid definitions in the text.

Agreed. I've removed the definitions in the text and added a
reference to Appendix A.

 > 4.  I don't like this sentence for independent.
 > 
 >        The only rights this PC has are those granted explicitly to it. 
 > 
 > 	I suggest
 > 
 > 	The only rights the holder of this PC has are those explicitly
 > granted by other  means than the proxy certificate.

But this isn't technically correct as there could be rights granted
directly to the identity in the PC.

-end-

Date: Wed, 07 May 2003 20:24:09 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-pkix-pi
Sender: [email-masked]

Russ,

> Mike:
> 
> No.  At this point, we are asking questions.
> 
> Russ
> 
> At 05:46 PM 4/25/2003 -0700, Michael Myers wrote:
> 
>> >
>> >IdentifierType ::= CHOICE {
>> >    registeredOID         OBJECT IDENTIFIER,
>> >    uri                   IA5String }

The text says:

    The IdentifierType field may contain a registeredOID in the form of :

            a) an Object Identifier (i.e. an OID), or
            b) a *permanent* URI using IA5String.

    Characteristically, when an OID is used, the prefix of the OID
    identifies the organization, and a suffix is used to identify the
    type of permanent identifier being identified.  Essentially the
    same thing is true of URI’s.

In fact, the same thing is not fully true for URIs. This is only true if the 
URI is *permanent* and the only URI that currently has that characteristics 
is: www.w3.org.

I have had many discussions on that topic with Tom, but personnaly, since 
The IESG asked the question, I would delete uri and keep only registeredOID, 
since the concept of permanent URIs does not exist (if a URI is not paid 
during some period of time, it may be sold to another organisation).

W3C in its statutes mentions that it will pay for ever to keep that URI. 
Since some "old" organisations like the MIT are part of W3C, it is likely 
that some money will be available to pay for that URI still for a long time.

Currently, W3C is only willing to provider URIs under its own URI for 
companies/organisations that are members of W3C.

Denis

>>
>> Russ,
>>
>> Please clarify.  Is the IESG saying the WG MUST eliminate the
>> CHOICE and so select a single type?
>>
>> Mike
> 
> 
> 

Date: Wed, 07 May 2003 20:07:19 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Miguel Rodriguez <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP response in CMS
Sender: [email-masked]

Miguel,

> OCSP response in a CMS (pkcs #7), as it is for CRLs or time stamps?

Take a look at RFC 3126:

4.2.2  Complete Revocation Refs Attribute Definition

    The Complete Revocation Refs attribute is an unsigned attribute.
    Only a single instance of this attribute must occur with an
    electronic signature.  It references the full set of the CRL or OCSP
    responses that have been used in the validation of the signer and CA
    certificates used in ES with Complete validation data.

    The following object identifier identifies the CompleteRevocationRefs
    attribute:

id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22}

    The complete revocation refs attribute value has the ASN.1 syntax
    CompleteRevocationRefs.

    CompleteRevocationRefs ::=  SEQUENCE OF CrlOcspRef

Denis

> Thanks,
> Miguel A. Rodriguez
> Software Engineer
> SeguriDATA

Date: Tue, 06 May 2003 01:16:08 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Question about the edition of RFC 3280
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Denis:

I find your report stilted.  In particular it omits any discussion of the 
last paragraph of the key usage section (that is, the last paragraph of 
section 4.2.1.3 of RFC 3280).  I repeat it here:

    This profile does not restrict the combinations of bits that may be
    set in an instantiation of the keyUsage extension.  However,
    appropriate values for keyUsage extensions for particular algorithms
    are specified in [PKIXALGS].

I completely disagree with your claim that Tim Polk did not fully 
understand this issue.  This is simply incorrect.

I am not going to participate in another email debate about the semantics 
of these two key usage bits.  The authors and chairs and area directors did 
the best that we could to capture the lack of consensus on this 
point.  Denis feels that we missed the mark.  Others have posted comments 
to the contrary.

I am going to wait for the ISO / ITU-T proposed text before I make any 
further comments on this subject.  I hope everyone else will do the same.

Russ

Date: Mon, 05 May 2003 21:12:17 -0400
To: "Michael Myers" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-pi
Sender: [email-masked]

Mike:

No.  At this point, we are asking questions.

Russ

At 05:46 PM 4/25/2003 -0700, Michael Myers wrote:
> >
> >IdentifierType ::= CHOICE {
> >    registeredOID         OBJECT IDENTIFIER,
> >    uri                   IA5String }
>
>Russ,
>
>Please clarify.  Is the IESG saying the WG MUST eliminate the
>CHOICE and so select a single type?
>
>Mike

Date: Tue, 6 May 2003 14:39:09 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: OCSP response in CMS
Sender: [email-masked]

"Miguel Rodriguez" <[email-masked]> writes:

>Hi! Can anyone say if there's a standard or guideline on how to store an OCSP
>response in a CMS (pkcs #7), as it is for CRLs or time stamps?

Sure, draft-gutmann-ocsp-rtcs-00.txt is OCSP in a pure CMS format (-00 is
rather out-of-date, there's a new version due out Real Soon Now).

Peter.

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: time stamp of a CMS with multiple signatures
Date: Mon, 5 May 2003 19:58:07 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C31340.A9AA4990
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi! 
 
In TSP (RFC 3161) appendix A there's a guideline on how to store a time
stamp in a CMS, and it says that the messageImprint shall be the hash of
the signature field within the SignerInfo  for the SignedData being
timestamped. What should be the messageImprint for a SignedData with
multiple SignerInfo fields?
 
Thanks,
 
Miguel A. Rodriguez
Software Engineer
SeguriDATA

------=_NextPart_000_0006_01C31340.A9AA4990
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Arial Narrow";
	panose-1:2 11 5 6 2 2 2 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi! <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In TSP (RFC 3161) appendix A there&#8217;s a =
guideline on
how to store a time stamp in a CMS, and it says that the <span =
class=3DSpellE>messageImprint</span>
shall be the hash of the signature field within the <span =
class=3DSpellE><span
class=3DGramE>SignerInfo</span></span><span class=3DGramE> <span
style=3D'mso-spacerun:yes'>&nbsp;</span>for</span> the <span =
class=3DSpellE>SignedData</span>
being <span class=3DSpellE>timestamped</span>. What should be the <span
class=3DSpellE>messageImprint</span> for a <span =
class=3DSpellE>SignedData</span>
with multiple <span class=3DSpellE>SignerInfo</span> =
fields?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Miguel A. =
Rodriguez</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Software =
Engineer</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>SeguriDATA</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DES-MX
style=3D'font-size:12.0pt;mso-ansi-language:ES-MX'><o:p>&nbsp;</o:p></spa=
n></font></p>

</div>

</body>

</html>

------=_NextPart_000_0006_01C31340.A9AA4990--

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: OCSP response in CMS
Date: Mon, 5 May 2003 19:52:16 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C3133F.D57703C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi! Can anyone say if there's a standard or guideline on how to store an
OCSP response in a CMS (pkcs #7), as it is for CRLs or time stamps?
 
Thanks,
 
Miguel A. Rodriguez
Software Engineer
SeguriDATA

------=_NextPart_000_0001_01C3133F.D57703C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Arial Narrow";
	panose-1:2 11 5 6 2 2 2 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi! Can anyone say if there&#8217;s a standard or =
guideline on
how to store an OCSP response in a CMS (<span class=3DSpellE>pkcs</span> =
#7), as
it is for <span class=3DSpellE>CRLs</span> or time =
stamps?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Miguel A. =
Rodriguez</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Software =
Engineer</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>SeguriDATA</span></font><span
lang=3DES-MX =
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DES-MX
style=3D'font-size:12.0pt;mso-ansi-language:ES-MX'><o:p>&nbsp;</o:p></spa=
n></font></p>

</div>

</body>

</html>

------=_NextPart_000_0001_01C3133F.D57703C0--

Date: Mon, 5 May 2003 11:50:12 -0700
From: "Hoyt L. Kesterson II" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Question about the edition of RFC 3280
Sender: [email-masked]

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Question about the edition of RFC
3280</title></head><body>
<div>you can always repudiate anything, even that it was your system
doing a key exchange. the question is whether you are
successful.</div>
<div><br></div>
<div>the defect report to which denis is referring is not that new and
is not being done as an alignment issue but in response to the obvious
confusion on this subject. the first version was drafted at a meeting
in september.</div>
<div><br></div>
<div>it has already had one ballot round but clearly still had some
problems. comments on that dtc were addressed at a meeting in london
in february with a revision of the dtc that will be resubmitted soon
for ballot. (i want to get the new pdam out first).</div>
<div><br></div>
<div>i don't want to discuss the proposed text here. please wait until
it is available to the group. however, one item of text in the first
proposal that was not contested in the ballot and is in the revised
dtc&nbsp; that will be balloted</div>
<div><br></div>
<blockquote><font face="Times New Roman" color="#000000">More than one
bit may be set in an instance of the</font><font face="Arial"
color="#000000"><b> keyUsage</b></font><font face="Times New Roman"
color="#000000"> extension. The setting of multiple bits shall not
change the meaning of each individual bit but indicates that the
certificate can be used for all of the purposes indicated by the set
bits.</font></blockquote>
<blockquote><br></blockquote>
<div>i discussed the conclusions of the group working on the dtc in my
two presentations at the rsa conference. if interested, you should be
able to find my slides on their conference presentation site</div>
<div><br></div>
<div>&nbsp;&nbsp;&nbsp; hoyt</div>
<div><br></div>
<div><br></div>
<div>At 17:58 +0200 5/5/03, Peter Sylvester wrote:</div>
<blockquote type="cite" cite>Thanks for your reply.<br>
<br>
Is the description of 'The Monday discussion'<br>
an agreed report shared by the participants of the meeting?<br>
<br>
<br>
A way forward<br>
<br>
&gt; In X.509 and RFC 2459 this bit is set when a digital signature
mechanism is being<br>
&nbsp; used, but not when the digital signature mechanism is used to
provide a non repudiation<br>
&nbsp; service. In RFC 3280, the later restriction has disappeared.
The signer is thus loosing<br>
&nbsp; its argument to repudiate its signature.<br>
<br>
Are you saying that with the new text, when there is ONLY<br>
the DS bit a signer is no longer able to repudiate a
signature?</blockquote>
<div><br></div>
</body>
</html>

Date: Mon, 5 May 2003 17:58:23 +0200 (MET DST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Question about the edition of RFC 3280
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Thanks for your reply. 

Is the description of 'The Monday discussion'
an agreed report shared by the participants of the meeting?

A way forward

> In X.509 and RFC 2459 this bit is set when a digital signature mechanism is being 
  used, but not when the digital signature mechanism is used to provide a non repudiation
  service. In RFC 3280, the later restriction has disappeared. The signer is thus loosing
  its argument to repudiate its signature.

Are you saying that with the new text, when there is ONLY
the DS bit a signer is no longer able to repudiate a signature? 

Date: Mon, 05 May 2003 17:10:50 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Sylvester <[email-masked]>, [email-masked]
CC: Tim Polk <[email-masked]>, Russ Housley <[email-masked]>, "Hoyt L. Kesterson II" <[email-masked]>
Subject: Re: Question about the edition of RFC 3280
Sender: [email-masked]

Peter,

> hi Denis,

> Do you have some result? 

Thank you for inquiring.

> regards
> Peter

The following people have participated to a meeting held on Monday April, 14 
during the RSA Security Conference :

  - Tim Polk, editor of RFC 3280 and PKIX co-chair;
  - Russ Housley, editor of RFC 3280 and recently designated as
    Security Area Director;
  - Denis Pinkas, PKIX participant;
  - Hoyt Kesterson, chair of the ISO/ITU SC 6 X.509 WG (partly);

History

The change was made during the 48 hours window period for editorial changes. 
The requestor for the change was Stefan Santesson. Neither Russ, Tim or 
Stefan have any record of the e-mail from Stefan that lead to that change.

Russ and Tim said, that in the opinion of the editors, the change that 
happened between draft 12 and RFC 3280 was purely editorial, to make it 
consistent with the sentence that has been added after a long debate 
("Further distinctions between the digitalSignature and nonRepudiation bits 
may be provided in specific certificate policies"). An observation was made 
that a simple way to resolve the consistency would have been to remove the 
additional sentence (which had been accepted on the basis that no other 
change was being made to the remaining text).

However, the RFC editor was wondering whether that change was really 
editorial, but both Steve Kent (co-chair of the PKIX WG) and Jeff Schiller 
(Security Area Director) confirmed that the change was editorial. The PKIX 
list has not been informed of the change.

The Monday discussion

 From the discussion that took place on the Monday, it appears that the 
rational for the use of bits 0 and 1 as defined in both X.509 and RFC 2459 
was not fully understood by Tim Polk.

The rational has to do with the use of private keys in untrusted 
environments: in an untrusted environment, a private key holder cannot make 
sure of the data that is being signed.

In a trusted environment, a private key holder is able to control the data 
that is being signed. For example, if the private key is used to sign 
contracts, the client software may display the contract on which a hash will 
be computed, or if the key is used for authentication purposes, the client 
software may combine the random value sent by a server with a random number 
chosen by the client software.

An example has been used to illustrate the problem:

A signature private key is being used for authentication purposes to open a 
door lock placed in an *untrusted* environment. The door lock sends a 
challenge and the challenge is signed. The signer has no control on the 
value of the challenge. If that challenge happened not to be to be a random 
number, but the hash of a contract, the signer would have signed the 
contract without knowing it ! Without an indication for the key usage it 
would be impossible for the signer to say that he only intended to sign a 
challenge but not a contract.

This is exactly why two bits are being used.

If the key is usable for authentication purposes, then the key usage bit 0 
shall be set.

If the key is usable for non-repudiation purposes, then the key usage bit 1 
shall be set.

In order to make the difference, the signer should use two certificates:

- one for non-repudiation purposes, that is only usable
   in trusted environments;

- one for authentication purposes, usable in any kind
   of environment (i.e.untrusted or trusted).

When using the door lock if a contract has been signed, the signer can say: 
a key corresponding for an authentication certificate has been used, so the 
contract is non valid since a certificate with the bit 1 set (the non 
repudiation bit) should have been used. Now, if the signer willingly 
recognizes that the signature is good, that fine, but it is similar as 
making a transaction with a credit card over the Internet: the card holder 
may repudiate the transaction at any time without the need to prove anything 
and independently of any context.

A certificate policy may further restrict the use of the certificate but may 
not override the meaning of the bits.

Now, if both bits are set in a certificate, what are the implications ?

The private key corresponding to that certificate can only be used safely, 
if always used in trusted environments. For example, a smart card protecting 
the private key is always used with client software trusted by the signer.

It may be observed that all key usage bits (except bit 0) are defined as 
security service bits, while bit 0 is defined as a security mechanism bit 
with the exception of a few security services (notably the non-repudiation 
service).

It would be better to define bit 0 as a service bit saying explicitly which 
are the security services for which the private key can be used for, namely 
an authentication service and/or an integrity service.

A way forward

The topic is being discussed within ISO SC 6 since a Defect Report has been 
raised. A "clarification" is indeed needed, but opinions differ whether it 
is really a "defect" or not. It is desirable to maintain alignment between 
the IETF RFCs and ISO X.509.

At this time it is too early to know which text will be proposed and adopted 
by ISO, but it is clear that the current text from RFC 3280 will *not* be 
used. As a matter of fact, RFC 3280 is no more backwards compatible with RFC 
2459 nor X.509, since the meaning of the DS bit has been changed. In X.509 
and RFC 2459 this bit is set when a digital signature mechanism is being 
used, but not when the digital signature mechanism is used to provide a non 
repudiation service. In RFC 3280, the later restriction has disappeared. The 
signer is thus loosing its argument to repudiate its signature.

When the new proposal from ISO will circulate, the PKIX WG should consider it.

A draft 3280bis document should be started now and include for the time 
being an indication which shall be placed in section 4.2.1.3 (Key Usage) to 
warn the reader that the text is not backward compatible with RFC 2459 and 
that section is subject to changes. People wishing to comply with the text 
from section 4.2.1.3 (Key Usage) from RFC 2459 will be unable to reference 
RFC 3280 until a new RFC is produced. However, X.509 (2000) can be 
referenced instead.

It is expected that ISO could agree on a final text in the September time-frame.

Denis

PS.Extracts from the Introduction of ISO 10181-4 (Non-repudiation 
Framework). "The goal of the Non-repudiation service is to collect, 
maintain, make available and validate irrefutable evidence concerning a 
claimed event or action in order to resolve disputes about the occurence or 
non-occurrence of the event or action".

"Non-repudiation involves the generation of evidence that can be used to 
prove some kind of event or action has taken place, so that this event or 
action cannot be repudiated later".

>>Date: Thu, 10 Apr 2003 10:54:54 +0200
>>From: Denis Pinkas <[email-masked]>
>>
>>Stefan,
>>
>>Thank you for the response.
>>
>>I realize that very unfortunately both the sender of the message and the 
>>receivers of the message lost the message. :-|
>>
>>Now, looking forward, I would like to make the following proposal:
>>
>>Next week there is the RSA 2003 Security Conference. I will attend the 
>>Conference and I guess may other people from the PKIX WG will do so as well.
>>
>>Since there is the speaker's dinner on the Tuesday and the Gala Dinner of 
>>the Wednesday, I propose to have an informal meeting about key usage bits 0 
>>and 1 on the Monday evening for anyone interrested.
>>
>>I thus propose to meet in the North Lobby, in front of the registration 
>>desks at 5:30 p.m. on the Monday evening.
>>
>>I would like to discuss the meaning of a certificate that has:
>>
>>  1° only the key usage bit 1 set,
>>  2° only the key usage bit 0 set,
>>  3° both the key usage bits 0 and 1 set.
>>
>>   ... when looking at the writing of RFC 2459 and
>>       when looking at the writing of RFC 3280.
>>
>>Denis
>>
> 
> 

Date: Mon, 05 May 2003 00:24:49 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: IPsec PKIX profile draft
Sender: [email-masked]

Steve Bellovin and myself would like to see support for certificates in 
IKEv2 become a SHOULD requirement.  The authors of this specification 
believe that it could apply to IKEv1 as well as IKEv2.  Perhaps all we need 
to do is reference this document.

Please review it.

Russ

At 03:19 PM 5/2/2003 -0700, Brian Korver wrote:

>For those of you who aren't on the IPsec list, I'd like to
>mention that a new revision of the IPsec PKIX profile draft
>is available.
>
>   http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-profile-02.txt
>
>This document would benefit greatly from review by additional
>PKI experts and vendors, especially those who are familiar with
>IPsec PKI deployment issues.  Comments should be sent to the
>[email-masked] mailing list.
>
>-brian
>[email-masked]

Date: Sun, 4 May 2003 01:14:09 -0700 (PDT)
From: Hamid Asadi <[email-masked]>
Subject: Request for CA Trust Evaluation 
To: [email-masked]
Sender: [email-masked]

--0-583861590-1052036049=:63030
Content-Type: multipart/alternative; boundary="0-446412801-1052036049=:63030"

--0-446412801-1052036049=:63030
Content-Type: text/plain; charset=us-ascii

Hello Dear Sir/Madamam Hamid Asadi,Master student form Isfahan University of Technology.I am working on Trust evaluation in public key infrastructure. Ms David Chadwick  purposed method that based on knowledge based system.But we wanna to make a new system that is differ from purposed method but we need to know  your view point about many questions about Certificate Authority.This email has a attachment . You can see  questions that Ms  David Chadwick   used for last method.we wanna you -if possible-  answer those questions according to a specific CPS like Verisign ,Entrust... and assign to each question a number between 0 and 10.If  You wanna answer Questions ,please write the CPS that has been used.You can see last method that emplemented at http://huan.isi.salford.ac.uk:7007/ . With best regardHamid AsadiElecterical and computer Dep.Isfahan University of Technology

---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.

---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
--0-446412801-1052036049=:63030
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV>
<DIV>
<DIV>
<DIV>
<DIV>Hello Dear Sir/Madam</DIV>
<DIV>am Hamid Asadi,Master student form <A href="http://www.iut.ac.ir/" target=_blank>Isfahan University of Technology</A>.</DIV>
<DIV>I am working on Trust evaluation in public key infrastructure. </DIV>
<DIV>Ms <A title="google Search..." href="http://www.google.com/search?q=[email-masked]" target=_blank>David Chadwick </A>&nbsp;purposed method that based on knowledge based system.</DIV>
<DIV>But we wanna to make a new system that is differ from purposed method but we need to know&nbsp; your view point about many questions about Certificate Authority.</DIV>
<DIV>This email has a attachment . You can see&nbsp; questions that</DIV>
<DIV>&nbsp;Ms&nbsp; <A title="google Search..." href="http://www.google.com/search?q=[email-masked]" target=_blank>David Chadwick </A>&nbsp; used for last method.</DIV>
<DIV>we wanna you -if possible-&nbsp; answer those questions according to a specific CPS like Verisign ,Entrust... and assign to each question a number between 0 and 10.If&nbsp; You wanna answer Questions ,please write the CPS that has been used.</DIV>
<DIV>You can see last method that emplemented at <A class=msgbody href="http://huan.isi.salford.ac.uk:7007/" target=_blank>http://huan.isi.salford.ac.uk:7007/</A>&nbsp;.</DIV>
<DIV>&nbsp;</DIV>
<DIV>With best regard</DIV>
<DIV>Hamid Asadi</DIV>
<DIV>Electerical and computer Dep.</DIV>
<DIV>Isfahan University of Technology</DIV></DIV></DIV>
<P>
<HR SIZE=1>
Do you Yahoo!?<BR><A href="http://us.rd.yahoo.com/search/mailsig/*http://search.yahoo.com">The New Yahoo! Search</A> - Faster. Easier. Bingo.</DIV></DIV></DIV><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/search/mailsig/*http://search.yahoo.com">The New Yahoo! Search</a> - Faster. Easier. Bingo.
--0-446412801-1052036049=:63030--
--0-583861590-1052036049=:63030
Content-Type: application/msword; name="Questions.doc"
Content-Transfer-Encoding: base64
Content-Description: Questions.doc
Content-Disposition: attachment; filename="Questions.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB
AAAALwAAAAAAAAAAEAAAMQAAAAEAAAD+////AAAAAC4AAAD/////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////

--0-583861590-1052036049=:63030--

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'IETF-PKIX'" <[email-masked]>
Subject: Proxy -05 comments
Date: Sun, 4 May 2003 00:00:38 -0700
Importance: Normal
Sender: [email-masked]

Comments are divided into two sections, those of substance and
nit-picking.

Substance:

1.  I still get confused because of the language used between PKC policy
and PC policy.  To clarify this I would like to see the following items
changed:

A) change acceptable-pc-policy-set to acceptable-pc-policy-language-set
B) change any-policy to any-policy-language and assign an OID for this
C) in 4.1.3 (c) the discription of the tuple is harder than it needs to
be.  "containing the certificate subject name, proxyPolicy, key usage
extension..."

2) The following text:
    *  InheritAll, as defined by the oid value iso(1) identified-
       organization(3) dod(6) internet(1) security(5) mechanisms(5) 
       pkix(7) ppl(21) inheritall(1)

	says that the ASN.1 module needs the following change

 id-ppl-inheritall           OBJECT IDENTIFIER ::= { id-ppl 1 } 
	
	to

 id-ppl-inheritall           OBJECT IDENTIFIER ::= { id-ppl
inheritall(1) } 

3)  The following text:
    *  Independent, as defined by the oid value iso(1) identified-
       organization(3) dod(6) internet(1) security(5) mechanisms(5) 
       pkix(7) ppl(21) independent(2)

	says that the ASN.1 module needs the following change

 id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl 2 } 

	to

 id-ppl-independent     OBJECT IDENTIFIER ::= { id-ppl independent(2) } 

4)  If I have the following chain of certificates, please explain why it
should be rejected

	EE	subject="cn=me"
	PC1	subject="cn=me,cn=1"  Policy=id-pp-inheritall
	PC2	subject="cn=me,cn=1,cn=1" Policy=MySpecialPolicy
	PC3	subject="cn=me,cn=1,cn=1,cn=1" Policy=id-pp-independent

If I set acceptable-pc-policy-set to "inheritall, independent" this get
rejected, but the evaluation code would seem to be fine in terms of
evaluating this policy as MySpecialPolicy does not get involved in
making any proxy decisions for PC3.  It's proxy rights are independent
of any previous statements.

Nits:

1.  Certificates don't issue anything, holders of certificates issue
things.  In section 2.1 I suggest the following text:

  * PI: A "Proxy Issuer" is an entity with an End Entity Certificate or
a Proxy Certificate that issues a Proxy Certificates.

2.  Sec 3.8 - second to last paragarph.  MUST NOT rather than MUST not
--- alt. MUST be absent.

3.  inheritAll and Independent oid definitions in the text.

4.  I don't like this sentence for independent.

       The only rights this PC has are those granted explicitly to it. 

	I suggest

	The only rights the holder of this PC has are those explicitly
granted by other  means than the proxy certificate.

Jim

From: Brian Korver <[email-masked]>
Subject: IPsec PKIX profile draft
To: [email-masked]
Date: Fri, 2 May 2003 15:19:21 -0700 (PDT)
Sender: [email-masked]

For those of you who aren't on the IPsec list, I'd like to
mention that a new revision of the IPsec PKIX profile draft
is available.

  http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-profile-02.txt

This document would benefit greatly from review by additional
PKI experts and vendors, especially those who are familiar with
IPsec PKI deployment issues.  Comments should be sent to the
[email-masked] mailing list.

-brian
[email-masked]

Date: Thu, 01 May 2003 14:11:44 -0400
To: Carlisle Adams <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: draft-ietf-pkix-rfc2511bis
Cc: [email-masked]
Sender: [email-masked]

<html>
<body>
Carlisle:<br><br>
Thanks for getting back to me.&nbsp; It would be very helpful if the
document included a section on changes since RFC 2511.&nbsp; We included
a similar section in RFC 3280 that describes the changes since RFC
2459.&nbsp; In that section, you can say that the inconsistency was
corrected.<br><br>
Can you post a proposal for such a section?<br><br>
Russ<br><br>
At 09:54 AM 5/1/2003 -0400, Carlisle Adams wrote:<br>
<blockquote type=cite class=cite cite><font color="#0000FF">Hi
Russ,</font><br>
&nbsp;<br>
<font color="#0000FF">In RFC 2511, the body of the spec (in Section 7, on
page 11) says that {id-regInfo 1} is called
&quot;id-regInfo-asciiPairs&quot; with a syntax of OCTET STRING, but the
ASN.1 module (a few lines before the END statement, on page 23) says that
this same OID is called &quot;id-regInfo-utf8Pairs&quot; with a syntax of
UTF8String.</font><br>
&nbsp;<br>
<font color="#0000FF">The change made in rfc2511bis was to correct this
error and align the text in the body of the spec with the ASN.1
module.&nbsp; Thus, both places now say that the {id-regInfo 1} OID is
called &quot;id-regInfo-utf8Pairs&quot; with a syntax of
UTF8String.&nbsp; There was no intent to change the semantics of an
existing OID.</font><br>
&nbsp;<br>
<font color="#0000FF">Carlisle.</font><br>
&nbsp;<br>
&nbsp;<br>

<dl>
<dd><font face="tahoma" size=2>-----Original Message-----<br>

<dd>From:</b> Russ Housley
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]<br>

<dd>Sent:</b> Tuesday, April 29, 2003 9:54 AM<br>

<dd>To:</b> [email-masked]<br>

<dd>Subject:</b> draft-ietf-pkix-rfc2511bis<br><br>
</font>
<dd>I am concerned about the change that is illustrated below (please
excuse the HTML).<br><br>
<br>

<dd><pre>&nbsp;&nbsp; -- Registration Info in CRMF

<dd>&nbsp;&nbsp; id-regInfo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT

<dd>IDENTIFIER ::= { id-pkip id-regInfo(2) }

<dd>&nbsp; 

<dd><font face="Courier New, Courier" color="#FF0000">id-regInfo-asciiPairs
</font>
<dd>&nbsp; 

<dd><font face="Courier New, Courier" color="#008000">id-regInfo-utf8Pairs</font>&nbsp;&nbsp; 

<dd>OBJECT IDENTIFIER ::= { id-regInfo 1 }

<dd>&nbsp;&nbsp; --with syntax

<dd><font face="Courier New, Courier" color="#FF0000">OCTET
STRING</font>

<dd><font face="Courier New, Courier" color="#008000">UTF8STRING
</font>
<dd>&nbsp;&nbsp; id-regInfo-certReq&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OBJECT IDENTIFIER ::= { id-regInfo 2 }

<dd>&nbsp;&nbsp; --with syntax CertRequest

</pre><font face="Courier New, Courier"></font>
<dd>First, I am concerned about the change in the semantics associated
with an OID that was assigned a long time ago.&nbsp; This could lead to
interoperability issues.&nbsp; Why would we change the semantics of an
existing OID instead of assigning a new OID.<br><br>

<dd>Second, this change does not show up in the ASN.1 module.&nbsp; Why
are the OIDs not part of the ASN.1 module?<br><br>

<dd>Russ <br>

</dl></blockquote></body>
</html>

From: Carlisle Adams <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-rfc2511bis
Date: Thu, 1 May 2003 09:54:18 -0400 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C30FE9.28FF4340
Content-Type: text/plain

Hi Russ,
 
In RFC 2511, the body of the spec (in Section 7, on page 11) says that
{id-regInfo 1} is called "id-regInfo-asciiPairs" with a syntax of OCTET
STRING, but the ASN.1 module (a few lines before the END statement, on page
23) says that this same OID is called "id-regInfo-utf8Pairs" with a syntax
of UTF8String.
 
The change made in rfc2511bis was to correct this error and align the text
in the body of the spec with the ASN.1 module.  Thus, both places now say
that the {id-regInfo 1} OID is called "id-regInfo-utf8Pairs" with a syntax
of UTF8String.  There was no intent to change the semantics of an existing
OID.
 
Carlisle.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Tuesday, April 29, 2003 9:54 AM
To: [email-masked]
Subject: draft-ietf-pkix-rfc2511bis

I am concerned about the change that is illustrated below (please excuse the
HTML).

   -- Registration Info in CRMF

   id-regInfo       OBJECT

IDENTIFIER ::= { id-pkip id-regInfo(2) }

id-regInfo-asciiPairs

id-regInfo-utf8Pairs   

OBJECT IDENTIFIER ::= { id-regInfo 1 }

   --with syntax

OCTET STRING

UTF8STRING

   id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }

   --with syntax CertRequest

First, I am concerned about the change in the semantics associated with an
OID that was assigned a long time ago.  This could lead to interoperability
issues.  Why would we change the semantics of an existing OID instead of
assigning a new OID.

Second, this change does not show up in the ASN.1 module.  Why are the OIDs
not part of the ASN.1 module?

Russ 

------_=_NextPart_001_01C30FE9.28FF4340
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">

<META content="MSHTML 6.00.2800.1141" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=086304813-01052003><FONT color=#0000ff>Hi 
Russ,</FONT></SPAN></DIV>
<DIV><SPAN class=086304813-01052003><FONT 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=086304813-01052003><FONT color=#0000ff>In RFC 2511, the body of 
the spec (in Section 7, on page 11) says that {id-regInfo 1} is called 
"id-regInfo-asciiPairs" with a syntax of OCTET STRING, but the ASN.1 module (a 
few lines before the END statement, on page 23) says that this same OID is 
called "id-regInfo-utf8Pairs" with a syntax of UTF8String.</FONT></SPAN></DIV>
<DIV><SPAN class=086304813-01052003><FONT 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=086304813-01052003><FONT color=#0000ff>The change made in 
rfc2511bis was to correct this error and align the text in the body of the spec 
with the ASN.1 module.&nbsp; Thus, both places now say that the {id-regInfo 1} 
OID is called "id-regInfo-utf8Pairs" with a syntax of UTF8String.&nbsp; There 
was no intent to change the semantics of an existing OID.</FONT></SPAN></DIV>
<DIV><SPAN class=086304813-01052003><FONT 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=086304813-01052003><FONT 
color=#0000ff>Carlisle.</FONT></SPAN></DIV>
<DIV><SPAN class=086304813-01052003><FONT 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=086304813-01052003><FONT 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Russ Housley 
  [mailto:[email-masked]]<BR><B>Sent:</B> Tuesday, April 29, 2003 9:54 
  AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> 
  draft-ietf-pkix-rfc2511bis<BR><BR></FONT></DIV>I am concerned about the change 
  that is illustrated below (please excuse the HTML).<BR><BR><PRE>&nbsp;&nbsp; -- Registration Info in CRMF
&nbsp;&nbsp; id-regInfo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT
IDENTIFIER ::= { id-pkip id-regInfo(2) }
&nbsp;&nbsp;
<FONT face="Courier New, Courier" color=#ff0000>id-regInfo-asciiPairs
</S></FONT>&nbsp;&nbsp;
<FONT face="Courier New, Courier" color=#008000>id-regInfo-utf8Pairs</B></FONT>&nbsp;&nbsp;&nbsp;
OBJECT IDENTIFIER ::= { id-regInfo 1 }
&nbsp;&nbsp; --with syntax
<FONT face="Courier New, Courier" color=#ff0000>OCTET STRING</S></FONT>
<FONT face="Courier New, Courier" color=#008000>UTF8STRING
</B></FONT>&nbsp;&nbsp; id-regInfo-certReq&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT IDENTIFIER ::= { id-regInfo 2 }
&nbsp;&nbsp; --with syntax CertRequest

</PRE>First, I am concerned about the change in the semantics associated with 
  an OID that was assigned a long time ago.&nbsp; This could lead to 
  interoperability issues.&nbsp; Why would we change the semantics of an 
  existing OID instead of assigning a new OID.<BR><BR>Second, this change does 
  not show up in the ASN.1 module.&nbsp; Why are the OIDs not part of the ASN.1 
  module?<BR><BR>Russ </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C30FE9.28FF4340--