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

["Kurt D. Zeilenga" <[e-mail]>]

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 <[e-mail]>.

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


>Date: Tue, 27 May 2003 14:12:49 -0700 (PDT)
>From: "RL 'Bob' Morgan" <[e-mail]>
>To: IETF ldapbis WG <[e-mail]>
>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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4S3FwAF089044 for <[e-mail]>; Tue, 27 May 2003 20:15:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4S3Fwb2089043 for ietf-pkix-bks; Tue, 27 May 2003 20:15:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4S3FeAF089036 for <[e-mail]>; Tue, 27 May 2003 20:15:56 -0700 (PDT) (envelope-from [e-mail])
Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h4S3Fhc6023047 for <[e-mail]>; Wed, 28 May 2003 03:15:43 GMT (envelope-from [e-mail])
Message-Id: <5.2.0.9.0.20030527201226.028f8c60@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 27 May 2003 20:12:51 -0700
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Fwd: ldapbis WG last call on draft-ietf-ldapbis-dn-10.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]>.

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


>Date: Tue, 27 May 2003 14:12:49 -0700 (PDT)
>From: "RL 'Bob' Morgan" <[e-mail]>
>To: IETF ldapbis WG <[e-mail]>
>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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NFbCAF026654 for <[e-mail]>; Fri, 23 May 2003 08:37:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4NFbCcZ026653 for ietf-pkix-bks; Fri, 23 May 2003 08:37:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mta9.adelphia.net (mta9.adelphia.net [64.8.50.199] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NFbAAF026645 for <[e-mail]>; Fri, 23 May 2003 08:37:11 -0700 (PDT) (envelope-from [e-mail])
Received: from Quark ([68.71.230.238]) by mta9.adelphia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030523153705.RWZY11419.mta9.adelphia.net@Quark> for <[e-mail]>; Fri, 23 May 2003 11:37:05 -0400
From: "Matt Cooper" <[e-mail]>
To: "'PKIX list'" <[e-mail]>
Subject: RE: RFC 3280: same certificate in a certification path
Date: Fri, 23 May 2003 11:37:38 -0400
Message-ID: <001c01c32141$3d7ae180$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <003901c320e4$4325f820$[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h4NFbBAF026648
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Matt Cooper
> Sent: Friday, May 23, 2003 12:32 AM
> To: [e-mail]; '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: [e-mail]
> > [mailto:[e-mail]] 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".
> > 
> > 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4N4VkAF064764 for <[e-mail]>; Thu, 22 May 2003 21:31:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4N4VkdM064763 for ietf-pkix-bks; Thu, 22 May 2003 21:31:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mta9.adelphia.net (mta9.adelphia.net [64.8.50.199] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4N4ViAF064748 for <[e-mail]>; Thu, 22 May 2003 21:31:44 -0700 (PDT) (envelope-from [e-mail])
Received: from Quark ([68.71.230.238]) by mta9.adelphia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20030523043131.MRNW11419.mta9.adelphia.net@Quark>; Fri, 23 May 2003 00:31:31 -0400
From: "Matt Cooper" <[e-mail]>
To: <[e-mail]>, "'PKIX list'" <[e-mail]>
Subject: RE: RFC 3280: same certificate in a certification path
Date: Fri, 23 May 2003 00:32:04 -0400
Message-ID: <003901c320e4$4325f820$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-reply-to: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h4N4VjAF064753
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] 
> [mailto:[e-mail]] 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".
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4MMeLAF053737 for <[e-mail]>; Thu, 22 May 2003 15:40:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4MMeLHw053736 for ietf-pkix-bks; Thu, 22 May 2003 15:40:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4MMeJAF053726 for <[e-mail]>; Thu, 22 May 2003 15:40:20 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 17:41:45 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: questions about RFC 3126
Date: Thu, 22 May 2003 17:40:51 -0500
Message-ID: <002d01c320b3$32b03770$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C32089.49DA2F70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-OriginalArrivalTime: 22 May 2003 22:41:45.0265 (UTC) FILETIME=[528C0A10:01C320B3]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:filelist.xml@01C32089.4973A570">
<!--[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--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4MH2SAF036344 for <[e-mail]>; Thu, 22 May 2003 10:02:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4MH2SCf036343 for ietf-pkix-bks; Thu, 22 May 2003 10:02:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from netscape.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4MH2RAF036336 for <[e-mail]>; Thu, 22 May 2003 10:02:27 -0700 (PDT) (envelope-from [e-mail])
Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id h4MH2JE23426 for <[e-mail]>; Thu, 22 May 2003 10:02:19 -0700 (PDT)
Received: from pc655301.nscp.aoltw.net ([10.169.25.82]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id HFASK400.CI2; Thu, 22 May 2003 10:00:04 -0700 
Date: Thu, 22 May 2003 10:02:23 -0700
From: [e-mail] (Terry Hayes)
Subject: Name Constraints Processing
To: [e-mail]
Message-ID: <[e-mail]>
X-Mailer: AOL Communicator (20030521.1 Win)
Organization: Netscape
MIME-Version: 1.0
Content-Type: TEXT/HTML; CHARSET=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!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@[e-mail]">"terry@[e-mail]"</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:[e-mail]">[e-mail]</a><br>
<br>
</font></font><font face="Arial,sans-serif"><font size="2">
</font></font>
</body>
</html>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4J9w9AF025118 for <[e-mail]>; Mon, 19 May 2003 02:58:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4J9w9tM025117 for ietf-pkix-bks; Mon, 19 May 2003 02:58:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4J9w8AF025112 for <[e-mail]>; Mon, 19 May 2003 02:58:08 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4J9w7sa005749; Mon, 19 May 2003 03:58:07 -0600 (MDT)
Received: from sydney.east.sun.com (esun1as-be21-ge0.Central.Sun.COM [129.147.60.148]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4J9vt407905; Mon, 19 May 2003 05:57:57 -0400 (EDT)
From: Steve Hanna <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 19 May 2003 05:59:29 -0400
To: "Eric Norman" <[e-mail]>, "PKIX list" <[e-mail]>
Reply-To: <[e-mail]>
Subject: Re: RFC 3280: same certificate in a certification path
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4J40sAF084024 for <[e-mail]>; Sun, 18 May 2003 21:00:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4J40sK6084023 for ietf-pkix-bks; Sun, 18 May 2003 21:00:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4J40qAF084010 for <[e-mail]>; Sun, 18 May 2003 21:00:53 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h4J40lqn032270; Mon, 19 May 2003 16:00:47 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h4J40mN29877; Mon, 19 May 2003 16:00:48 +1200
Date: Mon, 19 May 2003 16:00:48 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric Norman <[e-mail]> 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.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4J2DrAF082168 for <[e-mail]>; Sun, 18 May 2003 19:13:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4J2DrXB082167 for ietf-pkix-bks; Sun, 18 May 2003 19:13:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4J2DqAF082162 for <[e-mail]>; Sun, 18 May 2003 19:13:52 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 25735022 for [e-mail]; Sun, 18 May 2003 21:13:54 -0500
Date: Sun, 18 May 2003 21:13:54 -0500 (CDT)
From: Eric Norman <[e-mail]>
To: PKIX list <[e-mail]>
Subject: Re: RFC 3280: same certificate in a certification path
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-2140662931-1462719925-1053310434=:11100"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

  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 [e-mail] 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: <[e-mail]>
Content-Description: Mutually signed CA certs
Content-Disposition: attachment; filename="both.p7c"

MIIEmQYJKoZIhvcNAQcCoIIEijCCBIYCAQExADALBgkqhkiG9w0BBwGgggRu
MIICMzCCAd2gAwIBAgICAtEwDQYJKoZIhvcNAQEEBQAwgZYxCzAJBgNVBAYT
AlVTMRIwEAYDVQQIEwlXaXNjb25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAe
BgNVBAoTF1VuaXZlcnNpdHkgb2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZp
c2lvbiBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5MRIwEAYDVQQDEwlUZXN0
IENBIDEwHhcNMDMwNTE4MDExOTMyWhcNMTEwODA1MDExOTMyWjCBljELMAkG
A1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMHTWFkaXNv
bjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xKzApBgNVBAsT
IkRpdmlzaW9uIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kxEjAQBgNVBAMT
CVRlc3QgQ0EgMjBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDnizkH1UhjKXRD
gyfkr/tXSoKLTQqYgoeNhcq2JLBddxZqtX/KSujKKQJf54u2mV1UHS4n27gJ
w1PQx5oeEjPTAgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcN
AQEEBQADQQCFVaFlKOTZuQFCzq5zQZK/5gIdkj7AgT9+m95l4UveAx+Jh8ti
taXEOthYG1VXgjnpsbfXNmWukqbaUf+u89SeMIICMzCCAd2gAwIBAgICAtIw
DQYJKoZIhvcNAQEEBQAwgZYxCzAJBgNVBAYTAlVTMRIwEAYDVQQIEwlXaXNj
b25zaW4xEDAOBgNVBAcTB01hZGlzb24xIDAeBgNVBAoTF1VuaXZlcnNpdHkg
b2YgV2lzY29uc2luMSswKQYDVQQLEyJEaXZpc2lvbiBvZiBJbmZvcm1hdGlv
biBUZWNobm9sb2d5MRIwEAYDVQQDEwlUZXN0IENBIDIwHhcNMDMwNTE4MDEy
MjAzWhcNMTEwODA1MDEyMjAzWjCBljELMAkGA1UEBhMCVVMxEjAQBgNVBAgT
CVdpc2NvbnNpbjEQMA4GA1UEBxMHTWFkaXNvbjEgMB4GA1UEChMXVW5pdmVy
c2l0eSBvZiBXaXNjb25zaW4xKzApBgNVBAsTIkRpdmlzaW9uIG9mIEluZm9y
bWF0aW9uIFRlY2hub2xvZ3kxEjAQBgNVBAMTCVRlc3QgQ0EgMTBcMA0GCSqG
SIb3DQEBAQUAA0sAMEgCQQDMJAgRcpi0rjZeuJvdiJwKqpmmsX0MwxZlZVJB
awroBas0HBfLtzDJepA3rxJtFLzQhg5/MRtzmnn7CIikFQZTAgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADQQAiXjCvTLoHcLo0
wQPYBsPf9koSyRdL4rfWioaMVJ528KD87ppjgGE4Nzg+a8f2c19PGj+m6sSn
oniTMHqfJRJfMQA=
---2140662931-1462719925-1053310434=:11100--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4I5cQAF007263 for <[e-mail]>; Sat, 17 May 2003 22:38:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4I5cQHd007262 for ietf-pkix-bks; Sat, 17 May 2003 22:38:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4I5cOAF007255 for <[e-mail]>; Sat, 17 May 2003 22:38:25 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h4I5cJqn009291; Sun, 18 May 2003 17:38:19 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h4I5cJA15094; Sun, 18 May 2003 17:38:19 +1200
Date: Sun, 18 May 2003 17:38:19 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: RFC 3280: same certificate in a certification path
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric Norman <[e-mail]> 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.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4HNruAF099702 for <[e-mail]>; Sat, 17 May 2003 16:53:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4HNru6q099701 for ietf-pkix-bks; Sat, 17 May 2003 16:53:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4HNrtAF099696 for <[e-mail]>; Sat, 17 May 2003 16:53:56 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 25726302 for [e-mail]; Sat, 17 May 2003 18:53:57 -0500
Date: Sat, 17 May 2003 18:53:53 -0500 (CDT)
From: Eric Norman <[e-mail]>
To: PKIX list <[e-mail]>
Subject: Re: RFC 3280: same certificate in a certification path
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: MULTIPART/signed; BOUNDARY="-2140662931-719358168-1053215637=:11100"; protocol="application/x-pkcs7-signature"; micalg=sha1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

  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 [e-mail] 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"

MIIHNQYJKoZIhvcNAQcCoIIHJjCCByICAQExCzAJBgUrDgMCGgUAMAsGCSqG
SIb3DQEHAaCCBUswggKVMIIB/qADAgECAgICejANBgkqhkiG9w0BAQQFADCB
kTELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH
TWFkaXNvbjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xIDAe
BgNVBAsTF0ludGVybmV0MiBEZW1vbnN0cmF0aW9uMRgwFgYDVQQDEw9IRVBL
SSBDbGllbnQgQ0EwHhcNMDIwODI0MTkwNjE5WhcNMDMwOTI5MTkwNjE5WjCB
vzELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH
TWFkaXNvbjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xKzAp
BgNVBAsTIkRpdmlzaW9uIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kxFDAS
BgNVBAMTC0VyaWMgTm9ybWFuMSUwIwYJKoZIhvcNAQkBFhZlam5vcm1hbkBk
b2l0Lndpc2MuZWR1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALReNRkixlpT
urV2ogd3BCWgxihjl0j6+a7EGnV+SCCBsqjWqKcVTCedD49lTbHLnmgejUd+
tfdiy5Dg+//ZpMUCAwEAAaMQMA4wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B
AQQFAAOBgQB/5AydG4TKKO6ZFiI9d/m03260pf4lBp81mlD3B9IQl0ofJ1gl
NtZlTZyC1N4x+c82eqMNBIBrcA/dcaoy0LyNWRrRtt+et+JkNXfrhLuwUWtQ
NR8Gq3i00C2th4DienwNbh9FoVo6gru6sC3i4TRxwKnDbKus6r2xvKlOQt3E
azCCAq4wggIXoAMCAQICAgG/MA0GCSqGSIb3DQEBBAUAMIGRMQswCQYDVQQG
EwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAw
HgYDVQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50
ZXJuZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBD
QTAeFw0wMTA3MTcxODI0MzFaFw0yMzA2MTMxODI0MzFaMIGRMQswCQYDVQQG
EwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAw
HgYDVQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50
ZXJuZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBD
QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA6xU1OJP0g+mU9srwrQLC
zWXAMlkv3DKb+lEugUQTTV8/bi+ZgcG3oan7ZcxpiN+k+3biz8vcxIbxCMcI
NZvi0u0mdDoLjaAtZtqvORMgbm3XkJhzgtGMmaxFLUBlhebSdd7YeV4/X4lJ
FAIE3hcaXWayirI+jwGkaD0UgELs3ysCAwEAAaMTMBEwDwYDVR0TAQH/BAUw
AwEB/zANBgkqhkiG9w0BAQQFAAOBgQCkRVbjdpKkibnoRNqoDGWxu1Bno4eS
pw0GlIwkveeyhURWvBA2neUzBuFlG2JinTx7/YtHYf19vwzN+GSEzv7cUl0l
p27Uc0iamMYxzCCkgSvwgOn87FrdNgVA6e1QYvjzu0XdvbVyBqr0zH5a0Cel
/kzV7l/+idyjGPeNHC1lqzGCAbIwggGuAgEBMIGYMIGRMQswCQYDVQQGEwJV
UzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAwHgYD
VQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50ZXJu
ZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBDQQIC
AnowCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0wMzA1MTcyMzUzNTZaMCMGCSqGSIb3DQEJBDEWBBRf
o5iuSHc9/PYsbi/ZFernZXkEkDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3
DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN
BggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAARAX4h6z48EifNyVh1cE1nX
//08PibezYPaIyqMHxJdoPIXcAiOLDjp5vYHpTA9kYuiABSVLZqNeyeLQo1N
RkZ9+A==
---2140662931-719358168-1053215637=:11100--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GFVFAF098635 for <[e-mail]>; Fri, 16 May 2003 08:31:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4GFVEXl098634 for ietf-pkix-bks; Fri, 16 May 2003 08:31:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4GFVCAF098622 for <[e-mail]>; Fri, 16 May 2003 08:31:12 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4GFV2x9018147; Fri, 16 May 2003 08:31:07 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4GFV1409416; Fri, 16 May 2003 11:31:01 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 16 May 2003 11:28:32 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Norman <[e-mail]>
CC: PKIX list <[e-mail]>
Subject: Re: RFC 3280: same certificate in a certification path
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4G3p6AF038935 for <[e-mail]>; Thu, 15 May 2003 20:51:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4G3p6fv038934 for ietf-pkix-bks; Thu, 15 May 2003 20:51:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4G3p3AF038926 for <[e-mail]>; Thu, 15 May 2003 20:51:03 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h4G3p0qn031958; Fri, 16 May 2003 15:51:00 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h4G3owA32006; Fri, 16 May 2003 15:50:58 +1200
Date: Fri, 16 May 2003 15:50:58 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: RFC 3280: same certificate in a certification path
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard Levitte - VMS Whacker <[e-mail]> 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.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FJ96AF022438 for <[e-mail]>; Thu, 15 May 2003 12:09:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4FJ96Vl022437 for ietf-pkix-bks; Thu, 15 May 2003 12:09:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FJ93AF022431 for <[e-mail]>; Thu, 15 May 2003 12:09:05 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 25671206 for [e-mail]; Thu, 15 May 2003 14:09:01 -0500
Date: Thu, 15 May 2003 14:09:00 -0500 (CDT)
From: Eric Norman <[e-mail]>
To: PKIX list <[e-mail]>
Subject: Re: RFC 3280: same certificate in a certification path
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FHg9AF018251 for <[e-mail]>; Thu, 15 May 2003 10:42:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4FHg9F4018250 for ietf-pkix-bks; Thu, 15 May 2003 10:42:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FHg8AF018238 for <[e-mail]>; Thu, 15 May 2003 10:42:08 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA14053 for <[e-mail]>; Thu, 15 May 2003 10:42:03 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4FHg2405077; Thu, 15 May 2003 13:42:02 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 15 May 2003 13:39:34 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX List <[e-mail]>
Subject: Re: RFC 3280: same certificate in a certification path
References: <01d701c31ad9$464a84a0$[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <01d701c31ad9$464a84a0$[e-mail]> on Thu, 15 May 2003 20:58:18 +0900, Takashi ITO <[e-mail]> 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: [phone] |                             | SWEDEN
> >      "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FHbuAF018089 for <[e-mail]>; Thu, 15 May 2003 10:37:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4FHbuA5018088 for ietf-pkix-bks; Thu, 15 May 2003 10:37:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FHbtAF018082 for <[e-mail]>; Thu, 15 May 2003 10:37:55 -0700 (PDT) (envelope-from [e-mail])
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h4FHawbd015786; Thu, 15 May 2003 13:36:58 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 15 May 2003 13:36:48 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], [e-mail], [e-mail]
Subject: X.509 path validation test suite
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 [e-mail] 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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FGLPAF014887 for <[e-mail]>; Thu, 15 May 2003 09:21:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4FGLPGf014886 for ietf-pkix-bks; Thu, 15 May 2003 09:21:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FGLNAF014877 for <[e-mail]>; Thu, 15 May 2003 09:21:24 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4FGLOY9013961; Thu, 15 May 2003 10:21:24 -0600 (MDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4FGLN419315; Thu, 15 May 2003 12:21:23 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 15 May 2003 12:18:54 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Richard Levitte - VMS Whacker <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: RFC 3280: same certificate in a certification path
References: <01d701c31ad9$464a84a0$[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <01d701c31ad9$464a84a0$[e-mail]> on Thu, 15 May 2003 20:58:18 +0900, Takashi ITO <[e-mail]> 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: [phone] |                             | SWEDEN
>      "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FFBrAF008329 for <[e-mail]>; Thu, 15 May 2003 08:11:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4FFBrvQ008327 for ietf-pkix-bks; Thu, 15 May 2003 08:11:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FFBoAF008298 for <[e-mail]>; Thu, 15 May 2003 08:11:51 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (212.247.5.91) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 15 May 2003 17:10:07 +0200
Date: Thu, 15 May 2003 17:06:17 +0200 (CEST)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: RFC 3280: same certificate in a certification path
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <01d701c31ad9$464a84a0$[e-mail]>
References: <01d701c31ad9$464a84a0$[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.2, Mew version 3.2
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <01d701c31ad9$464a84a0$[e-mail]> on Thu, 15 May 2003 20:58:18 +0900, Takashi ITO <[e-mail]> 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: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FF95AF007979 for <[e-mail]>; Thu, 15 May 2003 08:09:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4FF95PP007977 for ietf-pkix-bks; Thu, 15 May 2003 08:09:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FF93AF007970 for <[e-mail]>; Thu, 15 May 2003 08:09:03 -0700 (PDT) (envelope-from [e-mail])
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA17125; Thu, 15 May 2003 08:08:57 -0700 (PDT)
Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4FF8u408849; Thu, 15 May 2003 11:08:56 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 15 May 2003 11:06:26 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Takashi ITO <[e-mail]>
CC: [e-mail]
Subject: Re: RFC 3280: same certificate in a certification path
References: <01d701c31ad9$464a84a0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]>
> Mitsubishi Electric Corporation


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FBwWAF095874 for <[e-mail]>; Thu, 15 May 2003 04:58:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4FBwWei095873 for ietf-pkix-bks; Thu, 15 May 2003 04:58:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx03.melco.co.jp (mx03.melco.co.jp [192.218.140.143]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4FBwUAF095868 for <[e-mail]>; Thu, 15 May 2003 04:58:30 -0700 (PDT) (envelope-from [e-mail])
Received: from mr03.melco.co.jp (unknown [133.141.98.157]) by mx03.melco.co.jp (Postfix) with ESMTP id D2B2257F10 for <[e-mail]>; Thu, 15 May 2003 20:58:29 +0900 (JST)
Received: from elgw.isl.melco.co.jp (localhost [127.0.0.1]) by mr03.melco.co.jp (Postfix) with ESMTP id B1DB016D542 for <[e-mail]>; Thu, 15 May 2003 20:58:29 +0900 (JST)
Received: from elmail by elgw.isl.melco.co.jp (8.12.9+Sun/3.7W) id h4FBwTm7018926; Thu, 15 May 2003 20:58:29 +0900 (JST)
Received: from iss.isl.melco.co.jp (iss.isl.melco.co.jp [10.74.5.60]) by elmail.isl.melco.co.jp (iPlanet Messaging Server 5.0 Patch 3 (built Mar 23 2001)) with ESMTP id <[e-mail]>; Thu, 15 May 2003 20:58:29 +0900 (JST)
Received: from jos818 by iss.isl.melco.co.jp (8.8.8/3.6W) id UAA14856; Thu, 15 May 2003 20:58:28 +0900 (JST)
Date: Thu, 15 May 2003 20:58:18 +0900
From: Takashi ITO <[e-mail]>
Subject: RFC 3280: same certificate in a certification path
To: [e-mail]
Message-id: <01d701c31ad9$464a84a0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300
X-Mailer: Microsoft Outlook Express 5.50.4920.2300
Content-type: text/plain; charset=iso-2022-jp
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]>
Mitsubishi Electric Corporation



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CNHLi2045178 for <[e-mail]>; Mon, 12 May 2003 16:17:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4CNHLep045177 for ietf-pkix-bks; Mon, 12 May 2003 16:17:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CNHKi2045172 for <[e-mail]>; Mon, 12 May 2003 16:17:21 -0700 (PDT) (envelope-from [e-mail])
Received: from catalyst2b.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.12.3/8.12.3/LLNL evision: 1.3 $) with ESMTP id h4CNH71R028209; Mon, 12 May 2003 16:17:08 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 12 May 2003 16:13:56 -0700
To: "todd glassey" <[e-mail]>, "el-sign: electronic signatures - open discussion" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Fw: I want to coin a term if I can... its called "Digital Perjury"...
Cc: "Tina Bird" <[e-mail]>
In-Reply-To: <01c001c318cf$e5745850$020aff0a@tsg1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
>To: <[e-mail]>
>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
>[e-mail]  - unsubscribe st-isc

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CLkTi2042243 for <[e-mail]>; Mon, 12 May 2003 14:46:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4CLkTUU042242 for ietf-pkix-bks; Mon, 12 May 2003 14:46:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CLkOi2042229 for <[e-mail]>; Mon, 12 May 2003 14:46:24 -0700 (PDT) (envelope-from [e-mail])
Received: from tsg1 (8.sanfrancisco-12rh16rt-ca.dial-access.att.net[12.81.119.8]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <20030512214618111005gehje>; Mon, 12 May 2003 21:46:19 +0000
Message-ID: <01c001c318cf$e5745850$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "el-sign: electronic signatures - open discussion" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "Tina Bird" <[e-mail]>
Subject: Fw: I want to coin a term if I can... its called "Digital Perjury"...
Date: Mon, 12 May 2003 14:45:57 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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" <[e-mail]>
To: <[e-mail]>
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
[e-mail]  - unsubscribe st-isc



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CEpCi2016694 for <[e-mail]>; Mon, 12 May 2003 07:51:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4CEpCAe016693 for ietf-pkix-bks; Mon, 12 May 2003 07:51:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CEpBi2016687 for <[e-mail]>; Mon, 12 May 2003 07:51:11 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17235; Mon, 12 May 2003 10:48:11 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-06.txt
Date: Mon, 12 May 2003 10:48:11 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CBQri2000399 for <[e-mail]>; Mon, 12 May 2003 04:26:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4CBQrNb000398 for ietf-pkix-bks; Mon, 12 May 2003 04:26:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CBQqi2000393 for <[e-mail]>; Mon, 12 May 2003 04:26:52 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08549; Mon, 12 May 2003 07:23:50 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-06.txt
Date: Mon, 12 May 2003 07:23:49 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h49Ikmi2080830 for <[e-mail]>; Fri, 9 May 2003 11:46:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h49IkmkH080829 for ietf-pkix-bks; Fri, 9 May 2003 11:46:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h49Ikki2080824 for <[e-mail]>; Fri, 9 May 2003 11:46:47 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 8299 invoked by uid 0); 9 May 2003 18:46:02 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.183.163) by woodstock.binhost.com with SMTP; 9 May 2003 18:46:02 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 09 May 2003 14:46:12 -0400
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: draft-ietf-pkix-pi-06
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h49FAOi2067897 for <[e-mail]>; Fri, 9 May 2003 08:10:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h49FANqJ067896 for ietf-pkix-bks; Fri, 9 May 2003 08:10:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h49FAKi2067888 for <[e-mail]>; Fri, 9 May 2003 08:10:21 -0700 (PDT) (envelope-from [e-mail])
Received: from VON-TP-T30 (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h49FAEt142822; Fri, 9 May 2003 10:10:14 -0500
X-Mailer: 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid (via feedmail 10 I); VM 7.07 under 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid
From: "Von Welch" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Fri, 9 May 2003 10:11:23 -0500
To: <[e-mail]>
Cc: "'IETF-PKIX'" <[e-mail]>
Subject: RE: Proxy -05 comments
In-Reply-To: <000e01c315d7$a04a6d50$[e-mail]>
References: <[e-mail]> <000e01c315d7$a04a6d50$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] 
 > > [mailto:[e-mail]] On Behalf Of Von Welch
 > > Sent: Thursday, May 08, 2003 11:41 AM
 > > To: [e-mail]
 > > 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
 > >  > 
 > > 
 > 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4945Ai2009838 for <[e-mail]>; Thu, 8 May 2003 21:05:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4945AQG009837 for ietf-pkix-bks; Thu, 8 May 2003 21:05:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h49458i2009831 for <[e-mail]>; Thu, 8 May 2003 21:05:08 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h494559X124534; Fri, 9 May 2003 00:05:05 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h49454iO143776; Fri, 9 May 2003 00:05:04 -0400
To: Denis Pinkas <[e-mail]>
Cc: Russ Housley <[e-mail]>, [e-mail], [e-mail]
MIME-Version: 1.0
Subject: Re: draft-ietf-pkix-pi
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 9 May 2003 00:04:59 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.1 w/SPR JHEG5JQ5CD|February 20, 2003) at 05/09/2003 00:05:04, Serialize complete at 05/09/2003 00:05:04
Content-Type: multipart/alternative; boundary="=_alternative 00166B2485256D21_="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]>
Sent by: [e-mail]
05/07/2003 02:24 PM

=20
        To:     Russ Housley <[e-mail]>
        cc:     [e-mail]
        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: [e-mail]=
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;[e-mail]&gt;</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbs=
p; &nbsp; &nbsp; &nbsp;[e-mail]</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_=--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4937Zi2008418 for <[e-mail]>; Thu, 8 May 2003 20:07:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4937ZDB008417 for ietf-pkix-bks; Thu, 8 May 2003 20:07:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4937Yi2008412 for <[e-mail]>; Thu, 8 May 2003 20:07:34 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip124.164-173-207.eli-du.nwlink.com [207.173.164.124]) by smtp3.pacifier.net (Postfix) with ESMTP id 34F376D69D; Thu,  8 May 2003 20:07:32 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Laura Pearlman'" <[e-mail]>, "'Von Welch'" <[e-mail]>
Cc: <[e-mail]>, "'IETF-PKIX'" <[e-mail]>
Subject: RE: Proxy -05 comments 
Date: Thu, 8 May 2003 20:07:33 -0700
Message-ID: <000f01c315d8$261649e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Laura Pearlman
> Sent: Thursday, May 08, 2003 3:21 PM
> To: Von Welch
> Cc: [e-mail]; '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
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4935Ni2008163 for <[e-mail]>; Thu, 8 May 2003 20:05:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4935NMl008162 for ietf-pkix-bks; Thu, 8 May 2003 20:05:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4935Li2008155 for <[e-mail]>; Thu, 8 May 2003 20:05:22 -0700 (PDT) (envelope-from [e-mail])
Received: from VON-TP-T30 (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h4934Xt12206; Thu, 8 May 2003 22:04:44 -0500
X-Mailer: 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid (via feedmail 10 I); VM 7.07 under 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid
From: "Von Welch" <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 8 May 2003 22:05:40 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Laura Pearlman <[e-mail]>
Cc: [e-mail], "'IETF-PKIX'" <[e-mail]>
Subject: Re: Proxy -05 comments 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
 > 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4933oi2008125 for <[e-mail]>; Thu, 8 May 2003 20:03:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4933okr008124 for ietf-pkix-bks; Thu, 8 May 2003 20:03:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4933ni2008119 for <[e-mail]>; Thu, 8 May 2003 20:03:49 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip124.164-173-207.eli-du.nwlink.com [207.173.164.124]) by smtp1.pacifier.net (Postfix) with ESMTP id D330E6F17E; Thu,  8 May 2003 20:03:49 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Von Welch'" <[e-mail]>, <[e-mail]>
Cc: "'IETF-PKIX'" <[e-mail]>
Subject: RE: Proxy -05 comments
Date: Thu, 8 May 2003 20:03:52 -0700
Message-ID: <000e01c315d7$a04a6d50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Von Welch
> Sent: Thursday, May 08, 2003 11:41 AM
> To: [e-mail]
> 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
>  > 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48MKpi2000376 for <[e-mail]>; Thu, 8 May 2003 15:20:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h48MKpVs000375 for ietf-pkix-bks; Thu, 8 May 2003 15:20:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48MKoi2000370 for <[e-mail]>; Thu, 8 May 2003 15:20:50 -0700 (PDT) (envelope-from [e-mail])
Received: from margay.isi.edu (margay.isi.edu [128.9.64.250]) by vapor.isi.edu (8.11.6p2/8.11.2) with ESMTP id h48MKqJ10795; Thu, 8 May 2003 15:20:52 -0700 (PDT)
Received: from margay.isi.edu (laura@localhost) by margay.isi.edu (8.12.8/8.12.7) with ESMTP id h48MKq7I002578; Thu, 8 May 2003 15:20:52 -0700
Message-Id: <[e-mail]>
X-Authentication-Warning: margay.isi.edu: laura owned process doing -bs
To: "Von Welch" <[e-mail]>
cc: [e-mail], "'IETF-PKIX'" <[e-mail]>
Subject: Re: Proxy -05 comments 
In-Reply-To: <[e-mail]> 
Date: Thu, 08 May 2003 15:20:51 -0700
From: Laura Pearlman <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48Idei2090223 for <[e-mail]>; Thu, 8 May 2003 11:39:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h48IdesP090222 for ietf-pkix-bks; Thu, 8 May 2003 11:39:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48Idci2090215 for <[e-mail]>; Thu, 8 May 2003 11:39:38 -0700 (PDT) (envelope-from [e-mail])
Received: from VON-TP-T30 (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h48IdNt173242; Thu, 8 May 2003 13:39:24 -0500
X-Mailer: 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid (via feedmail 10 I); VM 7.07 under 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid
From: "Von Welch" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 8 May 2003 13:40:30 -0500
To: <[e-mail]>
Cc: "'IETF-PKIX'" <[e-mail]>
Subject: RE: Proxy -05 comments
In-Reply-To: <000a01c31585$631eea70$[e-mail]>
References: <[e-mail]> <000a01c31585$631eea70$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
 > 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48HcAi2088278 for <[e-mail]>; Thu, 8 May 2003 10:38:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h48HcA4e088277 for ietf-pkix-bks; Thu, 8 May 2003 10:38:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.28]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48Hc9i2088271 for <[e-mail]>; Thu, 8 May 2003 10:38:09 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (195.111-30-212.9massy1-1-ro-as-i4-1.9tel.net [212.30.111.195]) by huva.hittite.isp.9tel.net (Postfix) with ESMTP id 443B19BB30 for <[e-mail]>; Thu,  8 May 2003 19:37:59 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Thu, 08 May 2003 19:40:53 +0200
From: Jean-Marc Desperrier <[e-mail]>
Organization: totalement desorganise
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030129
X-Accept-Language: en-us, en, fr, fr-fr, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: time stamp of a CMS with multiple signatures
References: <000501c3136a$92805190$[e-mail]>
In-Reply-To: <000501c3136a$92805190$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48HFDi2087359 for <[e-mail]>; Thu, 8 May 2003 10:15:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h48HFDsv087358 for ietf-pkix-bks; Thu, 8 May 2003 10:15:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48HFCi2087353 for <[e-mail]>; Thu, 8 May 2003 10:15:12 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip171.126-173-207.eli-du.nwlink.com [207.173.126.171]) by smtp1.pacifier.net (Postfix) with ESMTP id 9BF016F03F; Thu,  8 May 2003 10:15:09 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Von Welch'" <[e-mail]>
Cc: "'IETF-PKIX'" <[e-mail]>
Subject: RE: Proxy -05 comments
Date: Thu, 8 May 2003 10:15:09 -0700
Message-ID: <000a01c31585$631eea70$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47Kc1i2000312 for <[e-mail]>; Wed, 7 May 2003 13:38:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47Kc1Du000311 for ietf-pkix-bks; Wed, 7 May 2003 13:38:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47Kbxi2000305 for <[e-mail]>; Wed, 7 May 2003 13:37:59 -0700 (PDT) (envelope-from [e-mail])
Received: from VON-TP-T30 (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h47Kbmt17280; Wed, 7 May 2003 15:37:48 -0500
X-Mailer: 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid (via feedmail 10 I); VM 7.07 under 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid
From: "Von Welch" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 7 May 2003 15:38:54 -0500
To: <[e-mail]>
Cc: "'IETF-PKIX'" <[e-mail]>
Subject: Re: Proxy -05 comments
In-Reply-To: <005a01c3120a$dedd16b0$[e-mail]>
References: <005a01c3120a$dedd16b0$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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-



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47IODi2091716 for <[e-mail]>; Wed, 7 May 2003 11:24:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47IODqv091714 for ietf-pkix-bks; Wed, 7 May 2003 11:24:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47IOCi2091706 for <[e-mail]>; Wed, 7 May 2003 11:24:12 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id UAA14892; Wed, 7 May 2003 20:27:44 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id UAA30160; Wed, 7 May 2003 20:23:14 +0200
Message-ID: <[e-mail]>
Date: Wed, 07 May 2003 20:24:09 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-pi
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h47IODi2091709
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47I7Xi2090992 for <[e-mail]>; Wed, 7 May 2003 11:07:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47I7Xri090991 for ietf-pkix-bks; Wed, 7 May 2003 11:07:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47I7Vi2090985 for <[e-mail]>; Wed, 7 May 2003 11:07:32 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id UAA35984; Wed, 7 May 2003 20:11:01 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id UAA30102; Wed, 7 May 2003 20:06:24 +0200
Message-ID: <[e-mail]>
Date: Wed, 07 May 2003 20:07:19 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Miguel Rodriguez <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP response in CMS
References: <000001c31369$be4850d0$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h465GBi2023168 for <[e-mail]>; Mon, 5 May 2003 22:16:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h465GBpO023167 for ietf-pkix-bks; Mon, 5 May 2003 22:16:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h465G9i2023162 for <[e-mail]>; Mon, 5 May 2003 22:16:09 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 26614 invoked by uid 0); 6 May 2003 05:15:28 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (64.134.82.239) by woodstock.binhost.com with SMTP; 6 May 2003 05:15:28 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 06 May 2003 01:16:08 -0400
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Question about the edition of RFC 3280
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h464pKi2022430 for <[e-mail]>; Mon, 5 May 2003 21:51:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h464pKUM022429 for ietf-pkix-bks; Mon, 5 May 2003 21:51:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h464pIi2022420 for <[e-mail]>; Mon, 5 May 2003 21:51:19 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 25712 invoked by uid 0); 6 May 2003 04:50:37 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (64.134.82.239) by woodstock.binhost.com with SMTP; 6 May 2003 04:50:37 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 05 May 2003 21:12:17 -0400
To: "Michael Myers" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-pi
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h462dFi2018993 for <[e-mail]>; Mon, 5 May 2003 19:39:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h462dFQV018992 for ietf-pkix-bks; Mon, 5 May 2003 19:39:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h462dCi2018973 for <[e-mail]>; Mon, 5 May 2003 19:39:13 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h462d9MB005022; Tue, 6 May 2003 14:39:09 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h462d9C06682; Tue, 6 May 2003 14:39:09 +1200
Date: Tue, 6 May 2003 14:39:09 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: OCSP response in CMS
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Miguel Rodriguez" <[e-mail]> 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.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h460uKi2016492 for <[e-mail]>; Mon, 5 May 2003 17:56:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h460uKHY016491 for ietf-pkix-bks; Mon, 5 May 2003 17:56:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h460uJi2016483 for <[e-mail]>; Mon, 5 May 2003 17:56:19 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([148.233.248.105]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 5 May 2003 19:57:48 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: time stamp of a CMS with multiple signatures
Date: Mon, 5 May 2003 19:58:07 -0500
Message-ID: <000501c3136a$92805190$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C31340.A9AA4990"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 06 May 2003 00:57:48.0125 (UTC) FILETIME=[82F7E0D0:01C3136A]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:filelist.xml@01C31340.A587A1F0">
<!--[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--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h460oPi2016391 for <[e-mail]>; Mon, 5 May 2003 17:50:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h460oPDl016390 for ietf-pkix-bks; Mon, 5 May 2003 17:50:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h460oNi2016381 for <[e-mail]>; Mon, 5 May 2003 17:50:23 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([148.233.248.105]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 5 May 2003 19:51:51 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: OCSP response in CMS
Date: Mon, 5 May 2003 19:52:16 -0500
Message-ID: <000001c31369$be4850d0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C3133F.D57703C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 06 May 2003 00:51:51.0656 (UTC) FILETIME=[AE7F0680:01C31369]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:filelist.xml@01C3133F.D3313270">
<!--[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--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45J57i2005709 for <[e-mail]>; Mon, 5 May 2003 12:05:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45J57sv005708 for ietf-pkix-bks; Mon, 5 May 2003 12:05:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mpls-qmqp-04.inet.qwest.net (mpls-qmqp-04.inet.qwest.net [63.231.195.115]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h45J56i2005703 for <[e-mail]>; Mon, 5 May 2003 12:05:06 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 86408 invoked by uid 0); 5 May 2003 19:05:06 -0000
Received: from mpls-pop-04.inet.qwest.net (63.231.195.4) by mpls-qmqp-04.inet.qwest.net with QMQP; 5 May 2003 19:05:06 -0000
Received: from vdsl-130-13-127-251.phnx.uswest.net (HELO ?192.168.2.7?) (130.13.127.251) by mpls-pop-04.inet.qwest.net with SMTP; 5 May 2003 19:05:05 -0000
Date: Mon, 5 May 2003 11:50:12 -0700
Message-Id: <a05210602badc5d606d84@[192.168.2.7]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
X-Sender: [e-mail]@mail.earthlink.net
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Question about the edition of RFC 3280
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Fwci2000117 for <[e-mail]>; Mon, 5 May 2003 08:58:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45Fwcx4000116 for ietf-pkix-bks; Mon, 5 May 2003 08:58:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Fwai2000109 for <[e-mail]>; Mon, 5 May 2003 08:58:37 -0700 (PDT) (envelope-from [e-mail])
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA27293; Mon, 5 May 2003 17:58:25 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Mon, 5 May 2003 17:58:25 +0200 (MET DST)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id RAA29393; Mon, 5 May 2003 17:58:23 +0200 (MET DST)
Date: Mon, 5 May 2003 17:58:23 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Question about the edition of RFC 3280
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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? 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45FCEi2094549 for <[e-mail]>; Mon, 5 May 2003 08:12:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45FCEsk094548 for ietf-pkix-bks; Mon, 5 May 2003 08:12:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45FCBi2094541 for <[e-mail]>; Mon, 5 May 2003 08:12:12 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA31278; Mon, 5 May 2003 17:15:33 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id RAA08822; Mon, 5 May 2003 17:09:54 +0200
Message-ID: <[e-mail]>
Date: Mon, 05 May 2003 17:10:50 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>, [e-mail]
CC: Tim Polk <[e-mail]>, Russ Housley <[e-mail]>, "Hoyt L. Kesterson II" <[e-mail]>
Subject: Re: Question about the edition of RFC 3280
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h45FCDi2094544
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]>
>>
>>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
>>
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h454Thi2038072 for <[e-mail]>; Sun, 4 May 2003 21:29:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h454Th44038071 for ietf-pkix-bks; Sun, 4 May 2003 21:29:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h454Tgi2038066 for <[e-mail]>; Sun, 4 May 2003 21:29:42 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 27786 invoked by uid 0); 5 May 2003 04:29:01 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (64.134.126.230) by woodstock.binhost.com with SMTP; 5 May 2003 04:29:01 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 05 May 2003 00:24:49 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: IPsec PKIX profile draft
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
>[e-mail] mailing list.
>
>-brian
>[e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h448EOi2088616 for <[e-mail]>; Sun, 4 May 2003 01:14:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h448ENhd088615 for ietf-pkix-bks; Sun, 4 May 2003 01:14:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from web40810.mail.yahoo.com (web40810.mail.yahoo.com [66.218.78.187]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h448EJi2088609 for <[e-mail]>; Sun, 4 May 2003 01:14:20 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Received: from [62.145.53.247] by web40810.mail.yahoo.com via HTTP; Sun, 04 May 2003 01:14:09 PDT
Date: Sun, 4 May 2003 01:14:09 -0700 (PDT)
From: Hamid Asadi <[e-mail]>
Subject: Request for CA Trust Evaluation 
To: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-583861590-1052036049=:63030"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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=[e-mail]" 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=[e-mail]" 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/////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
///////////////////////spcIANyAJBAAA8BK/AAAAAAAAMAAAAAAABAAA
jxEAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAAAAAJBBYAHh4AADd8AAA3
fAAAjw0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAA
AAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAANoBAAAA
AAAA2gEAANoBAAAAAAAA2gEAAAAAAADaAQAAAAAAANoBAAAAAAAA2gEAABQA
AAAAAAAAAAAAAO4BAAAAAAAA6AgAAAAAAADoCAAAAAAAAOgIAAAAAAAA6AgA
AAwAAAD0CAAAHAAAAO4BAAAAAAAAVBcAALYAAAAcCQAAAAAAABwJAAAAAAAA
HAkAAAAAAAAcCQAAAAAAABwJAAAAAAAAHAkAAAAAAAAcCQAAAAAAABwJAAAA
AAAA0xYAAAIAAADVFgAAAAAAANUWAAAAAAAA1RYAAAAAAADVFgAAAAAAANUW
AAAAAAAA1RYAACQAAAAKGAAAIAIAACoaAACiAAAA+RYAABUAAAAAAAAAAAAA
AAAAAAAAAAAA2gEAAAAAAAAcCQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcCQAA
AAAAABwJAAAAAAAAHAkAAAAAAAAcCQAAAAAAAPkWAAAAAAAAYg4AAAAAAADa
AQAAAAAAANoBAAAAAAAAHAkAAAAAAAAAAAAAAAAAABwJAAAAAAAADhcAABYA
AABiDgAAAAAAAGIOAAAAAAAAYg4AAAAAAAAcCQAAUgAAANoBAAAAAAAAHAkA
AAAAAADaAQAAAAAAABwJAAAAAAAA0xYAAAAAAAAAAAAAAAAAAGIOAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAHAkAAAAAAADTFgAAAAAAAGIOAACgBAAAYg4AAAAAAAACEwAAVgAAAG8W
AABAAAAA2gEAAAAAAADaAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxxYAAAAAAAAcCQAA
AAAAABAJAAAMAAAA8F/NZRQSwwHuAQAA+gYAAOgIAAAAAAAAbgkAAFYCAACv
FgAADAAAAAAAAAAAAAAAxxYAAAwAAAAkFwAAMAAAAFQXAAAAAAAAuxYAAAwA
AADMGgAAAAAAAMQLAACeAgAAzBoAAAAAAADHFgAAAAAAAGIOAAAAAAAA7gEA
AAAAAADuAQAAAAAAANoBAAAAAAAA2gEAAAAAAADaAQAAAAAAANoBAAAAAAAA
AgDZAAAAIFF1ZXN0aW9ubmFpcmUgDQ0xLiBJZGVudGlmaWNhdGlvbiBhbmQg
QXV0aGVudGljYXRpb24NSW4gb3JkZXIgdG8gYmUgYWJsZSB0byB0cnVzdCB0
aGUgaWRlbnRpZmljYXRpb24gb2YgdGhlIHN1YmplY3QgaW4gdGhlIGNlcnRp
ZmljYXRlLCBob3cgaW1wb3J0YW50IGlzIGl0IHRoYXQgdGhlIENBOg0NYSlV
c2VzIGEgZ2xvYmFsbHkgcmVjb2duaXNlZCBuYW1lIGZvcm0NYilVc2VzIFRy
YWRlbWFya3MNYylVc2VzIG5hbWVzIHRoYXQgYXJlIGxvY2FsbHkgdW5pcXVl
IHRvIHRoZSBDQQ1kKVVzZXMgbmFtZXMgdGhhdCBhcmUgZ2xvYmFsbHkgdW5p
cXVlDWUpVXNlcyBuYW1lcyB0aGF0IGFyZSBtZWFuaW5nZnVsDWYpUHJvdmVz
IHRoYXQgdGhlIHN1YmplY3QgaXMgaW4gcG9zc2Vzc2lvbiBvZiB0aGUgcHJp
dmF0ZSBrZXkNZylBdXRoZW50aWNhdGVzIHRoZSBwZXJzb24NaClBdXRoZW50
aWNhdGVzIHRoZSBvcmdhbmlzYXRpb24gdGhlIHN1YmplY3Qgd29ya3MgZm9y
DWkpSGFzIGEgcml2YWwgbmFtZSBjbGFpbSByZXNvbHV0aW9uIHByb2NlZHVy
ZQ0NMi4gQ29tcGxpYW5jZSBBdWRpdA1Ib3cgaW1wb3J0YW50IHRvIHRydXN0
IGluIHRoZSBjb21wbGlhbmNlIGF1ZGl0IGFyZToNDWEpVGhlIGZyZXF1ZW5j
eSBvZiB0aGUgYXVkaXQNYilUaGUgcXVhbGlmaWNhdGlvbnMgb2YgdGhlIGF1
ZGl0b3INZClUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIENBIGFuZCBh
dWRpdG9yICh0aGF0IHRoZXkgYXJlIHN0YXRlZCBhbmQgYXBwcm9wcmlhdGUp
DWUpVGhlIGxpc3Qgb2YgY29tcGxpYW5jZSB0b3BpY3MgdGhhdCBhcmUgYXVk
aXRlZA1mKVRoZSB3aWRlIHNoYXJpbmcgb2YgdGhlIHJlc3VsdHMgb2YgdGhl
IGF1ZGl0DWcpVGhlIHNhbmN0aW9ucyB0aGF0IGNhbiBiZSBhcHBsaWVkIGZv
ciBhdWRpdCBkZWZpY2llbmN5DQ0zLiBDQSBQcm9jZWR1cmVzDUhvdyBpbXBv
cnRhbnQgZm9yIHRydXN0IGluIGEgY2VydGlmaWNhdGUgaXMgaXQgdGhhdDoN
DWEpVGhlIENBIGhhcyBlZmZlY3RpdmUgcHJpdmF0ZSBrZXkgcHJvdGVjdGlv
biBwcm9jZWR1cmVzIA1iKVRoZSBDQSBoYXMgZWZmZWN0aXZlIHByaXZhdGUg
a2V5IG1hbmFnZW1lbnQgcHJvY2VkdXJlcyAoZ2VuZXJhdGlvbiwgYmFja3Vw
LCBhcmNoaXZhbCwgcmVjb3ZlcnkpDWMpVGhlIENBIGhhcyBlZmZlY3RpdmUg
ZGlzYXN0ZXIgcmVjb3ZlcnkgcHJvY2VkdXJlcyAodG8gcmUtZXN0YWJsaXNo
IHRoZSBvcGVyYXRpb25hbCBlbnZpcm9ubWVudCkNZClUaGUgQ0EgaGFzIGVm
ZmVjdGl2ZSBzdWJqZWN0IGtleSByZXZvY2F0aW9uIHByb2NlZHVyZXMNZSlU
aGUgQ0EgaGFzIGVmZmVjdGl2ZSBzdWJqZWN0IGtleSBzdXNwZW5zaW9uIHBy
b2NlZHVyZXMNZilUaGUgbm90aWZpY2F0aW9uIG9mIGEgY2hhbmdlIG9mIENQ
UyAvcG9saWN5IGlzIHNwZWx0IG91dCBpbiB0aGUgQ1BTIChhbmQgd2UgYXNz
dW1lIGNhcnJpZWQgb3V0IGFjY29yZGluZyB0byB0aGUgcG9saWN5KS4NZylU
aGUgQ0EgaGFzIGVmZmVjdGl2ZSBwZXJzb25uZWwgcmVjcnVpdG1lbnQgYW5k
IHRyYWluaW5nIHByb2NlZHVyZXMNaClUaGUgQ0EncyByZXF1aXJlbWVudHMg
b24gdGhlIHVzZSBvZiByZXBvc2l0b3JpZXMgYXJlIGNsZWFyDQ00LiBPYmxp
Z2F0aW9ucyANSG93IGltcG9ydGFudCB0byB0cnVzdCBhcmUgdGhlIG9ibGln
YXRpb25zOiANDWEpRnJvbSB0aGUgQ0EgdG8gaXRzIHN1YmplY3QNYilGcm9t
IHRoZSBDQSB0byByZWx5aW5nIHBhcnRpZXMNYylPZiB0aGUgU3Vic2NyaWJl
cg1kKU9mIHRoZSBSZWx5aW5nIHBhcnR5DWYpT2YgdGhlIFJlcG9zaXRvcnkN
DTUuIE1hbHByYWN0aWNlIGFuZCBDb250cm9scw1Ib3cgaW1wb3J0YW50IHRv
IHRydXN0IGlzIGl0IHRoYXQgYXBwcm9wcmlhdGUgY29udHJvbHMgYXJlIGlu
IHBsYWNlIHNvIHRoYXQgbWFscHJhY3RpY2UgaXMgdmVyeSBkaWZmaWN1bHQg
dG8gcGVyZm9ybToNDWEpVGhlcmUgYXJlIGFwcHJvcHJpYXRlIHBoeXNpY2Fs
IHNlY3VyaXR5IGNvbnRyb2xzIChlLmcuIHBoeXNpY2FsIGFjY2VzcywgcG93
ZXIgcHJvdGVjdGlvbiwgZmlyZSBwcm90ZWN0aW9uKQ1iKVRoZXJlIGFyZSBh
cHByb3ByaWF0ZSBwZXJzb25uZWwgc2VjdXJpdHkgY29udHJvbHMgKGUuZy4g
YmFja2dyb3VuZCBjaGVja3MsIGpvYiByb3RhdGlvbikNYylUaGVyZSBhcmUg
YXBwcm9wcmlhdGUgcHJvY2VkdXJhbCBjb250cm9scyAoZS5nLiB0cnVzdGVk
IHJvbGVzLCBuIGZyb20gbSBhdXRob3Jpc2F0aW9ucykNZClUaGUgQ0EgaGFz
IGFuIGFwcHJvcHJpYXRlIGF1ZGl0IHRyYWlsICh0eXBlcyBvZiBldmVudHMg
cmVjb3JkZWQsIGVmZmVjdGl2ZSBwcm90ZWN0aW9uIG9mIGF1ZGl0IGxvZ3Mg
ZXRjLikNZSlUaGUgQ0EgaGFzIGFwcHJvcHJpYXRlIGFyY2hpdmUgcHJvY2Vk
dXJlcw1mKVRoZXJlIGFyZSBhcHByb3ByaWF0ZSBjb21wdXRlciBzZWN1cml0
eSBjb250cm9scyAoZWcuIHVzaW5nIGEgdHJ1c3RlZCBjb21wdXRpbmcgYmFz
ZSkNZylUaGVyZSBhcmUgYXBwcm9wcmlhdGUgbmV0d29yayBjb250cm9scyAo
ZS5nLiB1c2Ugb2YgYSBmaXJld2FsbCBvciBhaXIgZ2FwKQ0NDTYuIExlZ2Fs
IFJlZHJlc3MgDUhvdyBpbXBvcnRhbnQgdG8gdHJ1c3QgaXMgaXQgdGhhdDoN
DWEpVGhlIENBKENQUykgaGFzIGEgY29tcHJlaGVuc2l2ZSBzZXQgb2YgbGlh
YmlsaXRpZXMsIGRpc2NsYWltZXJzLCB3YXJyYW50aWVzDWMpVGhlIENQUyBz
dGF0ZXMgdGhlIGluZGVtbmlmaWNhdGlvbiBvZiB0aGUgQ0EgYnkgaXRzIHJl
cG9zaXRvcmllcw1kKVRoZSBDUFMgc3RhdGVzIHRoZSBpbmRlbW5pZmljYXRp
b24gb2YgdGhlIENBIGJ5IHRoZSBzdWJqZWN0cw1lKVRoZSBDUFMgc3RhdGVz
IHRoZSBpbmRlbW5pZmljYXRpb24gb2YgdGhlIENBIGJ5IHRoZSBSUHMNZilU
aGUgZ292ZXJuaW5nIGxhdyBpcyByZXNwZWN0YWJsZQ1nKVRoZSB1c2Ugb2Yg
dGhlIGNlcnRpZmljYXRlcyBieSB0aGUgdXNlcnMgaXMgbWFkZSBjbGVhciBp
biB0aGUgQ1BTPw0NNy4gT3ZlcmFsbA1Ib3cgaW1wb3J0YW50IHRvIHRydXN0
IGluIGFuIGlzc3VlZCBjZXJ0aWZpY2F0ZToNDWEpSXMgdGhlIGlkZW50aWZp
Y2F0aW9uIGFuZCBhdXRoZW50aWNhdGlvbiBvZiB0aGUgY2VydGlmaWNhdGUg
c3ViamVjdA1iKUlzIHRoZSBsZWdhbCByZWRyZXNzICh0aGUgY29tZSBiYWNr
KSB5b3UgaGF2ZSBvbiB0aGUgQ0ENYylJcyB0aGUgY3J5cHRvZ3JhcGhpYyBz
dGFuZGluZyBvZiB0aGUgYWxnb3JpdGhtcyB1c2VkIGJ5IHRoZSBDQSBzb2Z0
d2FyZQ1mKUFyZSB0aGUgY29udHJvbHMgYXBwbGllZCBieSB0aGUgQ0Egc28g
dGhhdCBpdCBpcyBkaWZmaWN1bHQgZm9yIG1hbHByYWN0aWNlIA1nKUFyZSB0
aGUgb2JsaWdhdGlvbnMgb2YgdGhlIHZhcmlvdXMgcGFydGllcw1oKUFyZSB0
aGUgcHJvY2VkdXJlcyBvZiB0aGUgQ0ENaSlpcyB0aGUgY29tcGxpYW5jZSBh
dWRpdA04LiBUcnVzdCBxdWVpdGVudCANSG93IG11Y2ggZG8geW91IHRydXN0
IHRoaXMgQ1BTPw0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEAAAPBAAAEAQAABEEAADRBAAA0gQAADgFAAA5BQAAsgUAALMF
AACRBwAAkgcAAEUKAABGCgAAhAoAAIUKAAChCgAAogoAAO0KAADuCgAAjxEA
AAD8+gD4APgA+AD6APgA+gD4APgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAADNQiBAzYIgQY1CIE2CIEUAAQAABAEAAARBAAANgQAAKoEAACr
BAAA0gQAAOQEAAATBQAAOQUAAFoFAACYBQAAswUAAOoFAAAYBgAAGQYAAC0G
AABhBgAAYgYAAH8GAACjBgAA+AYAACkHAABYBwAAkQcAAJIHAACjBwAA2AcA
ANkHAAATCAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD5AAAAAAAAAAAA
AAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAA
AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAA
AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA
AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPsAAAAAAAAA
AAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7
AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAA
AAAAAAAA+wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA
+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAAAAAEDAAABAAAAAQEAAB0ABAAA
jxEAAP4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAgEBARMIAAB1CAAA1wgAABAJAABJCQAAxAkAAAkKAABGCgAA
RwoAAFcKAACECgAAhQoAAKIKAADDCgAA1woAAO4KAAACCwAAAwsAAB8LAACV
CwAAlgsAAAMMAABeDAAAuAwAACQNAABQDQAAqA0AAPUNAAD2DQAA9w0AAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAA
AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAAAAAAAAAAAQMAAAEAAAAd9w0AAAkOAAAsDgAALQ4A
AHsOAAC+DgAA/Q4AADcPAABaDwAAnw8AAKAPAACrDwAA3A8AAN0PAAAjEAAA
XRAAAKcQAAD1EAAAIhEAAEERAABbEQAAbhEAAI4RAACPEQAA/QAAAAAAAAAA
AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA
AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAA
AAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7
AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAA
AAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA
+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAA
AAAAAAAAAPsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAQMA
ABccAB+wgi4gsMZBIbAIByKwCAcjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAABQAEQAKAAEAaQAPAAMAAAAAAAAAAAA0AABA
8f8CADQADAAGAE4AbwByAG0AYQBsAAAAAgAAABQAQ0oYAF9IAQRtSAkIc0gJ
CHRICQRKAAFAAQACAEoADAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAADQABAAYk
AROk8AAUpDwAABcANQiBQ0ogAEtIHABPSgIAUUoCAGtI5AQARAACAAEAAgBE
AAwACQBIAGUAYQBkAGkAbgBnACAAMgAAABAAAgAGJAETpPAAFKQ8AEAmAQ8A
NgiBQ0ocAE9KAgBRSgIAAEIAA0ABAAIAQgAMAAkASABlAGEAZABpAG4AZwAg
ADMAAAANAAMABiQBE6TwABSkPAAADwA1CIFPSgIAUUoCAGtI5AQAQgAEAAEA
AgBCAAwACQBIAGUAYQBkAGkAbgBnACAANAAAAA0ABAAGJAETpPAAFKQ8AAAP
ADYIgU9KAgBRSgIAa0jkBAAAAAAAAAAAAAAAPABBQPL/oQA8AAwAFgBEAGUA
ZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAA
AAAAAAAAAAAAIAD+DwEAAgEgAAwABABOAG8AdABlAAAAAgAQAAQAQ0oUAAAA
AACPDQAABAAAHgAAAAD/////AAAAABAAAAARAAAANgAAAKoAAACrAAAA0gAA
AOQAAAATAQAAOQEAAFoBAACYAQAAswEAAOoBAAAYAgAAGQIAAC0CAABhAgAA
YgIAAH8CAACjAgAA+AIAACkDAABYAwAAkQMAAJIDAACjAwAA2AMAANkDAAAT
BAAAdQQAANcEAAAQBQAASQUAAMQFAAAJBgAARgYAAEcGAABXBgAAhAYAAIUG
AACiBgAAwwYAANcGAADuBgAAAgcAAAMHAAAfBwAAlQcAAJYHAAADCAAAXggA
ALgIAAAkCQAAUAkAAKgJAAD1CQAA9gkAAPcJAAAJCgAALAoAAC0KAAB7CgAA
vgoAAP0KAAA3CwAAWgsAAJ8LAACgCwAAqwsAANwLAADdCwAAIwwAAF0MAACn
DAAA9QwAACINAABBDQAAWw0AAG4NAACODQAAkQ0AAAgAAAABMAAAAAAAAACA
AAAAgJgAAAAAMAAAAAAAAACAAAAAACgAAAADMAAAAAAAAACAAAAAAJgAAAAA
MAAAAAAAAACAEQAAAJgAAAAAMAAAAAAAAACAEQAAAJgAAAAAMAAAAAAAAACA
EQAAAJgAAAAAMAAAAAAAAACAEQAAAJgAAAAAMAAAAAAAAACAEQAAAJgAAAAA
MAAAAAAAAACAEQAAAJgAAAAAMAAAAAAAAACAEQAAAJgAAAAAMAAAAAAAAACA
EQAAAJgAAAAAMAAAAAAAAACAEQAAAJgAAAAAMAAAAAAAAACAEQAAAJgAAAAA
MAAAAAAAAACAEQAAAJgAAAAAAAAAAAAAAACAEQAAACgAAAADAAAAAAAAAACA
AAAAAJgAAAAAMAAAAAAAAACAGQIAAJgAAAAAMAAAAAAAAACAGQIAAJgAAAAA
MAAAAAAAAACAGQIAAJgAAAAAMAAAAAAAAACAGQIAAJgAAAAAMAAAAAAAAACA
GQIAAJgAAAAAMAAAAAAAAACAGQIAAJgAAAAAMAAAAAAAAACAGQIAAJgAAAAA
MAAAAAAAAACAGQIAAJgAAAAAAAAAAAAAAACAGQIAACgAAAADAAAAAAAAAACA
AAAAAJgAAAAAMAAAAAAAAACAkgMAAJgAAAAAMAAAAAAAAACAkgMAAJgAAAAA
MAAAAAAAAACAkgMAAJgAAAAAMAAAAAAAAACAkgMAAJgAAAAAMAAAAAAAAACA
kgMAAJgAAAAAMAAAAAAAAACAkgMAAJgAAAAAMAAAAAAAAACAkgMAAJgAAAAA
MAAAAAAAAACAkgMAAJgAAAAAMAAAAAAAAACAkgMAAJgAAAAAMAAAAAAAAACA
kgMAAJgAAAAAAAAAAAAAAACAkgMAACgAAAADAAAAAAAAAACAAAAAAJgAAAAA
MAAAAAAAAACARwYAAJgAAAAAMAAAAAAAAACARwYAAJgAAAAAMAAAAAAAAACA
RwYAAJgAAAAAMAAAAAAAAACARwYAAJgAAAAAMAAAAAAAAACARwYAAJgAAAAA
MAAAAAAAAACARwYAAJgAAAAAMAAAAAAAAACARwYAAJgAAAAAAAAAAAAAAACA
RwYAACgAAAADAAAAAAAAAACAAAAAAJgAAAAAAAAAAAAAAACAAwcAAJgAAAAA
AAAAAAAAAACAAwcAAJgAAAAAMAAAAAAAAACAAwcAAJgAAAAAMAAAAAAAAACA
AwcAAJgAAAAAMAAAAAAAAACAAwcAAJgAAAAAMAAAAAAAAACAAwcAAJgAAAAA
MAAAAAAAAACAAwcAAJgAAAAAMAAAAAAAAACAAwcAAJgAAAAAMAAAAAAAAACA
AwcAAJgAAAAAAAAAAAAAAACAAwcAAJgAAAAAAAAAAAAAAACAAwcAACgAAAAD
AAAAAAAAAACAAAAAAJgAAAAAAAAAAAAAAACA9wkAAJgAAAAAAAAAAAAAAACA
9wkAAJgAAAAAMAAAAAAAAACA9wkAAJgAAAAAMAAAAAAAAACA9wkAAJgAAAAA
MAAAAAAAAACA9wkAAJgAAAAAMAAAAAAAAACA9wkAAJgAAAAAMAAAAAAAAACA
9wkAAJgAAAAAMAAAAAAAAACA9wkAAJgAAAAAAAAAAAAAAACA9wkAACgAAAAD
AAAAAAAAAACAAAAAAJgAAAAAAAAAAAAAAACAoAsAAJgAAAAAAAAAAAAAAACA
oAsAAJgAAAAAMAAAAAAAAACAoAsAAJgAAAAAMAAAAAAAAACAoAsAAJgAAAAA
MAAAAAAAAACAoAsAAJgAAAAAMAAAAAAAAACAoAsAAJgAAAAAMAAAAAAAAACA
oAsAAJgAAAAAMAAAAAAAAACAoAsAAJgAAAAAMAAAAAAAAACAoAsAACgAAAAD
MAAAAAAAAACAAAAAAJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA
Ww0AAAAEAACPEQAACgAAAAAEAAATCAAA9w0AAI8RAAALAAAADQAAAA4AAAAA
BAAAjxEAAAwAAAAAAAAA6gEAAOsBAAAPBgAAEwYAAIQJAACGCQAAMwsAADYL
AABBDQAARQ0AAFsNAACODQAAkQ0AAAcAHAAHABwABwAcAAcAHAAHAAQABwAE
AAcAAAAAAKsAAACxAAAA0gAAANgAAADkAAAA6gAAABMBAAAZAQAAOQEAAD8B
AABaAQAAYgEAAJgBAACnAQAAswEAAMIBAADqAQAA7wEAAGICAABnAgAAfwIA
AIQCAACjAgAAqAIAAPgCAAD9AgAAKQMAAC4DAABYAwAAXQMAANkDAADeAwAA
EwQAABgEAAB1BAAAegQAANcEAADcBAAAEAUAABUFAABJBQAATgUAAMQFAADJ
BQAACQYAAA4GAACFBgAAiwYAAKIGAACoBgAAwwYAAMcGAADXBgAA2wYAAO4G
AADyBgAAlgcAAJ0HAAADCAAACggAAF4IAABlCAAAuAgAAL0IAAAkCQAAKQkA
AFAJAABXCQAAqAkAAK8JAAAtCgAAMgoAAHsKAACACgAAvgoAAMMKAAD9CgAA
AgsAADcLAAA8CwAAWgsAAF8LAADdCwAA4QsAACMMAAAnDAAAXQwAAGEMAACn
DAAArAwAAPUMAAD6DAAAIg0AACcNAABBDQAARQ0AAG4NAACODQAAkQ0AAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcABAAHAAAAAACNAAAAjQAAAKkAAACqAAAAqwAAAK0AAADS
AAAA1AAAAOQAAADmAAAAEwEAABUBAAA5AQAAOwEAAFoBAABcAQAAmAEAAJoB
AACzAQAAtQEAAOoBAADsAQAAYAIAAGECAABiAgAAZAIAAH8CAACBAgAAggIA
AIICAACjAgAApQIAAPgCAAD6AgAAKQMAACsDAABYAwAAWgMAANkDAADbAwAA
EwQAABUEAAB1BAAAdwQAANcEAADZBAAAEAUAABIFAABJBQAASwUAAMQFAADG
BQAACQYAAAsGAACDBgAAhAYAAIUGAACHBgAAogYAAKQGAADDBgAAxQYAANcG
AADZBgAA7gYAAPAGAACWBwAAmAcAAAMIAAAFCAAAXggAAGAIAAC4CAAAuggA
ACQJAAAmCQAAUAkAAFIJAACoCQAAqgkAAC0KAAAvCgAAewoAAH0KAAC+CgAA
wAoAAP0KAAD/CgAANwsAADkLAABaCwAAXAsAAN0LAADfCwAAIwwAACUMAABd
DAAAXwwAAKcMAACpDAAA9QwAAPcMAAAiDQAAJA0AAEENAABEDQAARQ0AAEUN
AABbDQAAjg0AAJENAAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE
AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA
AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD
AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA
BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE
AAMABAADAAQABwD//xQAAAAOAEQAYQB2AGkAZAAgAEMAaABhAGQAdwBpAGMA
awAhAEMAOgBcAFIARQBTAEUAQQBSAEMASABcAEkAQwBUAFwAVwBpAGUAZwBo
AHQAaQBuAGcAcwBRAHYAMwAuAGQAbwBjAA4ARABhAHYAaQBkACAAQwBoAGEA
ZAB3AGkAYwBrADYAQwA6AFwAdwBpAG4AZABvAHcAcwBcAFQARQBNAFAAXABB
AHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABXAGkA
ZQBnAGgAdABpAG4AZwBzAFEAdgAzAC4AYQBzAGQADgBEAGEAdgBpAGQAIABD
AGgAYQBkAHcAaQBjAGsANgBDADoAXAB3AGkAbgBkAG8AdwBzAFwAVABFAE0A
UABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAg
AFcAaQBlAGcAaAB0AGkAbgBnAHMAUQB2ADMALgBhAHMAZAAOAEQAYQB2AGkA
ZAAgAEMAaABhAGQAdwBpAGMAawAhAEMAOgBcAFIARQBTAEUAQQBSAEMASABc
AEkAQwBUAFwAVwBpAGUAZwBoAHQAaQBuAGcAcwBRAHYAMwAuAGQAbwBjAA4A
RABhAHYAaQBkACAAQwBoAGEAZAB3AGkAYwBrADYAQwA6AFwAdwBpAG4AZABv
AHcAcwBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMA
YQB2AGUAIABvAGYAIABXAGkAZQBnAGgAdABpAG4AZwBzAFEAdgAzAC4AYQBz
AGQADgBEAGEAdgBpAGQAIABDAGgAYQBkAHcAaQBjAGsAIQBDADoAXABSAEUA
UwBFAEEAUgBDAEgAXABJAEMAVABcAFcAaQBlAGcAaAB0AGkAbgBnAHMAUQB2
ADMALgBkAG8AYwAOAEQAYQB2AGkAZAAgAEMAaABhAGQAdwBpAGMAawAhAEMA
OgBcAFIAZQBzAGUAYQByAGMAaABcAEkAQwBUAFwAVwBpAGUAZwBoAHQAaQBu
AGcAcwBRAHYAMwAuAGQAbwBjAAsARAByACAAQwBoAGEAZAB3AGkAYwBrACQA
QwA6AFwAUgBlAHMAZQBhAHIAYwBoAFwATwBsAGQAIABQAHIAbwBqAGUAYwB0
AHMAXABJAEMAVABcAFEAdgAzAC4AZABvAGMABQBuADcAOQAwADcAQwBDADoA
XABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBz
AFwAbgA3ADkAMAA3AFwARABlAHMAawB0AG8AcABcAFcAaQBlAGcAaAB0AGkA
bgBnAHMAUQB2ADIAXABRAHUAZQBzAHQAaQBvAG4AcwAuAGQAbwBjAAUAbgA3
ADkANAA0ADUAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMA
ZQB0AHQAaQBuAGcAcwBcAG4ANwA5ADQANABcAEQAZQBzAGsAdABvAHAAXABR
AHUAZQBzAHQAaQBvAG4AcwAuAGQAbwBjAAMAKHfYBMKrmCL/D/8P/w//D/8P
/w//D/8P/w8BAHsmjQVmzPpH/w//D/8P/w//D/8P/w//D/8PAADcWAR2ZtK8
f/8PAAAAAAAAAAAAAAAAAAAAAAEAAQAAAAIAAQAAAAAAAAAAAAAAAAAAAAAA
AxgAAA+E0AIRhDD9FcYFAAHQAgZehNACYIQw/W8oAAIAAAApAAEAAAAAAAEA
AAAAAAAAAAAAAAAAAAAAAAAYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP4C
AAAALgABAAAAAAABAwAAAAAAAAAAAAAAAAAAAAAAGAAAD4QYAxGE6PwVxgUA
ARgDBl6EGANghOj8BAAAAC4AAQAuAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAA
AAAYAAAPhMgEEYQ4+xXGBQAByAQGXoTIBGCEOPsGAAAALgABAC4AAgAuAAEA
AAAAAAEDBQcAAAAAAAAAAAAAAAAAAAAYAAAPhMAGEYRA+RXGBQABwAYGXoTA
BmCEQPkIAAAALgABAC4AAgAuAAMALgABAAAAAAABAwUHCQAAAAAAAAAAAAAA
AAAAGAAAD4S4CBGE6PwVxgUAAdgJBl6EuAhghOj8CgAAAC4AAQAuAAIALgAD
AC4ABAAuAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAAYAAAPhLAKEYRY/BXG
BQABqAwGXoSwCmCEWPwMAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAEAAAAA
AAEDBQcJCw0AAAAAAAAAAAAAAAAYAAAPhKgMEYTI+xXGBQABEA4GXoSoDGCE
yPsOAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgABAAAAAAABAwUHCQsN
DwAAAAAAAAAAAAAAGAAAD4SgDhGEOPsVxgUAAeAQBl6EoA5ghDj7EAAAAC4A
AQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAEAAAAAAAEDBQcJCw0PEQAA
AAAAAAAAAAAYAAAPhOAQEYRg+hXGBQABsBMGXoTgEGCEYPoSAAAALgABAC4A
AgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAAuAAEAAAAEAAEAAAAAAAAAAAAA
AAAAAAAAAAYYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP41CAA2CAACAAAA
KQADAAAAeyaNBQAAAAAAAAAAAAAAANxYBHYAAAAAAAAAAAAAAAAod9gEAAAA
AAAAAAAAAAAA//////////////////8DAAAAAAAAAAAA//8DAAAAAAAAAAAA
AAAAAJENAAABAAAA/0ABgAEAjQ0AAI0NAAD4uHQAAQABAI0NAAAAAAAAXA0A
AAAAAAACEAAAAAAAAACPDQAAQAAACABAAAD//wEAAAAHAFUAbgBrAG4AbwB3
AG4A//8BAAgAAAAAAAAAAAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA
//8AAAAAAwAAAEcWkAEAAAICBgMFBAUCAwSHegAgAAAAgAgAAAAAAAAA/wEA
AAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUF
AQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAA
ADMmkAEAAAILBgQCAgICAgSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABBAHIA
aQBhAGwAAAAiAAQAMQiIGADw0AIAAGgBAAAAAEcddcYmI3UGAAAAAAYACgAA
APYBAAAuCwAAAQAFAAAABACDEBcAAAAAAAAAAAAAAAEAAQAAAAEAAAAAAAAA
JAMA8BAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAApQbAB7QAtACAADIwAAAQABkAZAAAABkAAAC6DQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbg0AAAAAAAAAAAAAAAAA
AAAAAAAAAAIAAAAAAAAAAAAAMoMRAPAQBN8DAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA//8SAAAAAAAAACkAVwBpAGUAZwBoAHQAaQBuAGcAcwAg
AGYAcgBvAG0AIABQAHIAbwBmACAAQQBuAHQAbwBuAGkAbwAgAEwAaQBvAHkA
LAAgAFQAbwByAGkAbgBvAAAAAAAAAA4ARABhAHYAaQBkACAAQwBoAGEAZAB3
AGkAYwBrAAUAbgA3ADkAMAA3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAA
AAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACAAQAAEAAAAAEA
AACIAAAAAgAAAJAAAAADAAAAxAAAAAQAAADQAAAABQAAAOgAAAAHAAAA9AAA
AAgAAAAEAQAACQAAABQBAAASAAAAIAEAAAoAAAA8AQAADAAAAEgBAAANAAAA
VAEAAA4AAABgAQAADwAAAGgBAAAQAAAAcAEAABMAAAB4AQAAAgAAAOQEAAAe
AAAAKgAAAFdpZWdodGluZ3MgZnJvbSBQcm9mIEFudG9uaW8gTGlveSwgVG9y
aW5vAHJkHgAAAAEAAAAAaWVnHgAAAA8AAABEYXZpZCBDaGFkd2ljawAgHgAA
AAEAAAAAYXZpHgAAAAcAAABOb3JtYWwAaB4AAAAGAAAAbjc5MDcAAGgeAAAA
AgAAADYAOTAeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDkuMABmQAAAAAC8oGUB
AAAAQAAAAABeEDiSEcMBQAAAAADwN0cUEsMBAwAAAAEAAAADAAAA9gEAAAMA
AAAuCwAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAA
AAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAAJAEAAAwAAAAB
AAAAaAAAAA8AAABwAAAABQAAAJAAAAAGAAAAmAAAABEAAACgAAAAFwAAAKgA
AAALAAAAsAAAABAAAAC4AAAAEwAAAMAAAAAWAAAAyAAAAA0AAADQAAAADAAA
AAYBAAACAAAA5AQAAB4AAAAWAAAAVW5pdmVyc2l0eSBvZiBTYWxmb3JkACAA
AwAAABcAAAADAAAABQAAAAMAAAC6DQAAAwAAAKAKCQALAAAAAAAAAAsAAAAA
AAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAKgAAAFdpZWdodGluZ3MgZnJv
bSBQcm9mIEFudG9uaW8gTGlveSwgVG9yaW5vAAwQAAACAAAAHgAAAAYAAABU
aXRsZQADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAA
AAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAA
DwAAAP7///8RAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAa
AAAAGwAAABwAAAAdAAAA/v///x8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUA
AAD+////JwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAP7////9////MAAA
AP7////+/////v//////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIA
AAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA4KnPZRQSwwEyAAAAgAAAAAAAAAAx
AFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAADgACAP///////////////wAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAADMGgAAAAAAAFcAbwByAGQA
RABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAaAAIBBQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4eAAAAAAAABQBTAHUAbQBtAGEAcgB5
AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAACgAAgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAeAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUA
bQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAAC
Af///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAACYAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIBAQAAAAYA
AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AGoAAAAAAAAATwBiAGoAZQBjAHQAUABvAG8AbAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQD///////////////8A
AAAAAAAAAAAAAAAAAAAAAAAAAOCpz2UUEsMB4KnPZRQSwwEAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABN
aWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3Jk
LkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

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


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4470fi2075727 for <[e-mail]>; Sun, 4 May 2003 00:00:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4470fOv075726 for ietf-pkix-bks; Sun, 4 May 2003 00:00:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4470ei2075721 for <[e-mail]>; Sun, 4 May 2003 00:00:40 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id 58F596A56E for <[e-mail]>; Sun,  4 May 2003 00:00:38 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'IETF-PKIX'" <[e-mail]>
Subject: Proxy -05 comments
Date: Sun, 4 May 2003 00:00:38 -0700
Message-ID: <005a01c3120a$dedd16b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h441sOi2058854 for <[e-mail]>; Sat, 3 May 2003 18:54:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h441sOki058853 for ietf-pkix-bks; Sat, 3 May 2003 18:54:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from oe8.briank.com (oe8.briank.com [198.144.201.197]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h441sNi2058847 for <[e-mail]>; Sat, 3 May 2003 18:54:23 -0700 (PDT) (envelope-from [e-mail])
Received: from oe8.briank.com (localhost [127.0.0.1]) by oe8.briank.com (8.12.3/8.12.3) with ESMTP id h441sLki039043 for <[e-mail]>; Sat, 3 May 2003 18:54:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from briank@localhost) by oe8.briank.com (8.12.3/8.12.3/Submit) id h441sKs4039042 for [e-mail]; Sat, 3 May 2003 18:54:20 -0700 (PDT)
From: Brian Korver <[e-mail]>
Message-Id: <[e-mail]>
Subject: IPsec PKIX profile draft
To: [e-mail]
Date: Fri, 2 May 2003 15:19:21 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-UID: 6906
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
[e-mail] mailing list.

-brian
[e-mail]


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41ICEi2073697 for <[e-mail]>; Thu, 1 May 2003 11:12:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41ICExg073696 for ietf-pkix-bks; Thu, 1 May 2003 11:12:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h41ICCi2073690 for <[e-mail]>; Thu, 1 May 2003 11:12:13 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 11137 invoked by uid 0); 1 May 2003 18:11:20 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.48.222) by woodstock.binhost.com with SMTP; 1 May 2003 18:11:20 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 01 May 2003 14:11:44 -0400
To: Carlisle Adams <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-rfc2511bis
Cc: [e-mail]
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<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:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]<br>

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

<dd>To:</b> [e-mail]<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>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41DsTi2061302 for <[e-mail]>; Thu, 1 May 2003 06:54:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41DsTtB061301 for ietf-pkix-bks; Thu, 1 May 2003 06:54:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41DsQi2061295 for <[e-mail]>; Thu, 1 May 2003 06:54:28 -0700 (PDT) (envelope-from [e-mail])
Received: from sottguard01.entrust.com (sottguard01.entrust.com [10.4.61.249]) by sottmxssm.entrust.com (Switch-2.2.6/Switch-2.2.4) with SMTP id V41D2FK616482 for <[e-mail]>; Thu, 01 May 2003 09:51:21 -0400
Received: (qmail 21780 invoked by uid 64014); 1 May 2003 13:52:28 -0000
Received: from [e-mail] by sottguard01.entrust.com with AmikaGuardian-Server-1.1.2 (Processed in 0.29983 secs); 01 May 2003 13:52:28 -0000
Received: from unknown (HELO SOTTMXS01.entrust.com) (10.4.61.7) by 10.4.61.249 with SMTP; 1 May 2003 13:52:28 -0000
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <KCLZASKJ>; Thu, 1 May 2003 09:54:20 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-rfc2511bis
Date: Thu, 1 May 2003 09:54:18 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30FE9.28FF4340"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]]
Sent: Tuesday, April 29, 2003 9:54 AM
To: [e-mail]
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:[e-mail]]<BR><B>Sent:</B> Tuesday, April 29, 2003 9:54 
  AM<BR><B>To:</B> [e-mail]<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--