RE: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt

["Turner, Sean P." <[e-mail]>]

David comments in-line.  I snipped out the ones that you accepted or you
resolved. 
------------------

> >4. Sec 4 1st para last sentence: remove required to support 
> a PKI.  All 
> >of the internet defined extensions are optional so they can't be 
> >required to support a PKI for the internet community.
> >  
> >
> The full sentence is "This section also defines private 
> extensions required to support a PKI for the Internet 
> community."  These extensions (authorityInfoAccess an 
> subjectInfoAccess) are needed even though it is not necessary 
> to include them in all certificates. 

Exactly - they are needed but not required. I still think the sentence ought
to read: This section also defines extension to support the PKI for the
internet community.  There's no need to say required. 
 
> >6. Sec 4.2.1.2: Can we suggest using something other than 
> SHA-1 for key 
> >id generation? How about striking SHA-1 from the methods and 
> adding the 
> >new sentence to both: The hash algorithm employed can be the same 
> >algorithm paired with the signature algorithm (e.g., SHA-1, 
> SHA-256, SHA-384).
> >  
> >
> Section 4.2.1.2 simply states that the two methods described 
> are two common methods for generating key identifiers.  The 
> text explicitly does not restrict CAs to using these methods.

This one didn't come across very well. I know there's no security issue and
there are just examples but sometimes people just implement the examples and
we end up getting stuck with those. Further I'm trying to avoid silly things
like somebody saying I won't use a spec that has SHA1 and they don't
understand that they're only examples.

> It is also not clear why one would want to use SHA-256, SHA-384, etc. 
> instead of SHA-1.  There are no security issues associated 
> with key identifiers, so it would seem that using a hash 
> algorithm with a longer output would just make the 
> certificates larger.

I wasn't clear with the use any hash algorithm part. I think the example
should still indicate that a 160bit output is used with whatever hash
algorithm is used. So for logner hash outputs they only use 160bits of it.
It doesn't matter which bits as long as the CA is consistent.
 
> >7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that 
> >since the SAN is bound to the public key that the CA MUST verify the 
> >each part of the SAN. I think a similar statement ought to 
> be added to 
> >the subject section (4.1.2.6) to indicate that "All parts of the 
> >subject name MUST be verified by the CA as it is bound to 
> the public key".
> >  
> >
> It is my understanding the the statement in 4.2.1.6 was added 
> because there were cases in which CAs were verifying the name 
> they included in the subject field but not names included in 
> the subjectAltName extension.  Are you aware of a similar 
> problem with the subject field?

No.  It was a motherhood and apple pie statement.
 
> >8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name 
> >constraints on ediPartyName or registeredID but the 14th 
> para (the one 
> >before the ASN.1) indicates that ediPartyName and 
> registeredId are not 
> >defined in this spec but MAY be defined in another spec. 
> Sounds to me 
> >like it would be hard to convince a customer that you could write a 
> >name constraints that can ever be 3280bis compliant since 
> whatever you 
> >wrote MUST NOT be imposed/implemented. It's not clear that the name 
> >constraints shouldn't be imposed because they're not defined in the 
> >spec or whether they should never ever be imposed.
> >  
> >
> 3280bis states:
> 
>       The syntax and semantics for name constraints for otherName,
>       ediPartyName, and registeredID are not defined by this 
> specification,
>       however syntax and semantics for name constraints for other name
>       forms may be specified in other documents.
> 
> A CA conforming to 3280bis MUST NOT impose name constraints 
> on the x400Address, ediPartyName, or registeredID name forms. 
>  Period.  
> However, just as [SRVSAN] specifies the syntax and semantics 
> for name constraints on the SRVName name form, other 
> documents could specify the syntax and semantics for name 
> constraints on other name forms.  Given that 3280bis forbids 
> conforming CAs from imposing name constraints on the 
> x400Address, ediPartyName, or registeredID name forms, it 
> would seem to be inappropriate for another PKIX (or even 
> IETF) document to specify syntax and semantics for name 
> constraints on ediPartyName or registeredID name forms, but 
> 3280bis is just one profile of X.509.  A different profile of 
> X.509 may permit the specification of name constraints on 
> these name forms and may specify the syntax and semantics for 
> imposing constraints on those name forms.  While 3280bis 
> states that conforming CAs MUST NOT impose name constraints 
> on these name forms, conforming relying parties are permitted 
> to implement the ability to process name constraints on these 
> name forms since conforming relying parties are not 
> restricted to only accepting certificates that are issued in 
> conformance with 3280bis.

I don't understand why these name forms were specifically picked out. For
x400Address I assume it's that nobody cares, but you could easily write a
rule that said the OR Address attributes (just like DNs) must be within the
ones included. I write the rules if we decide we need them. For registeredId
I get that it's an OID so there's structure to it so it's imposible to write
rules but why couldn't somebody decide to carve up an OID tree and say
something like make sure the 1st 6 components of the OID are present in all
names. For the ediPartyName you could say the nameAssigner must be present
in all PKCs.

If there is no way I can say with a straight face that a CA that requires a
name constraints for x400Address, ediPartyName, or registeredID is
compliant, I've got a problem with this what it says because being compliant
with RFC3280 is the gold standard; besides I think the rules are easy enough
to write I don't understand why these particular name forms were omitted
(there may be good reasons I'm unaware of).
 
> >9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name 
> >constraints on x400Address name forms but the last sentence 
> in the 10th 
> >para last says X400Address MUST be applied to x.400 
> addresses. See #8.
> >  
> >
> While a conforming CA MUST not impose name constraints on the 
> x400Address name form, a conforming relying party MAY 
> implement the ability to process  such constraints.  As with 
> any other name form, if a certificate includes name 
> constraint on the x400Address name form and a subsequent 
> certificate in the certification path includes a 
> subjectAltName extension with an x400Address name, the 
> relying party MUST either process the constraint or reject 
> the certification path.

See above.
 
> >13. Sec 5.2.5 8th para (one before the ASN.1): The sentence 
> about the 
> >onlyContainsAttributeCerts seems to hang. Recommend adding 
> "In either case"
> >to the beginning of the sentence to address the case when either 
> >onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. 
> >Additionally, recommend adding the following for 
> completeness as a new 
> >last paragraph: "If the scope of the CRL only includes attribute 
> >certificates then the onlyContainsAttributeCerts MUST be set to TRUE 
> >and both onlyContainsUserCerts and onlyContainsCACerts MUST 
> be set to FALSE."
> >  
> >
> This sentence was really meant to say that 
> onlyContainsAttributeCerts MUST be set to FALSE in all cases, 
> not just when either onlyContainsUserCerts or 
> onlyContainsCACerts is set to TRUE.  In order to make this 
> more clear, the sentence about onlyContainsAttributeCerts has 
> been moved to the end of the paragraph and now reads:
> 
>       Conforming CRLs issuers MUST set the 
> onlyContainsAttributeCerts boolean
>       to FALSE.

Are we not addressing the case when the CRL is only for attribute
certificates?

> >16. Sec 4.2.1.6 1st para: r These identities may be included in 
> >addition to or in the place of the identity/These identities may be 
> >included in addition to or in the place of, in the case of 
> non-CAs, the 
> >identity.  The paragraph mixes SAN and IAN, but assumed the 
> 2nd sentence addressed SAN.
> >  
> >
> Section 4.1.2.6 already very clearly states under what 
> circumstances a non-empty DN is required.  I don't think that 
> information needs to be repeated here.

I'm only hoping to clarify the 1st paragraph. It's unclear whether the
"these" refers to SAN or IAN after a couple of reads of the 1st para since
IAN is thrown in later in the paragraph.  If you add the ", in the case of
non-CAs," it's clear that the 2nd sentence refers to the SAN. 

> >17. Sec 4.2.1.6: Add the following to clarify that there is no 
> >dependency in this spec between SAN and IAN: This 
> specification places 
> >no requirement on CAs, whose certificate includes Issuer Alterative 
> >name, to include Subject Alternative names in certificates 
> issued by the CA.
> >  
> >
> While this statement is certainly true, I don't understand 
> the need to include it in section 4.2.1.6.  Is there any 
> reason that readers of 3280bis would believe that any 
> certificate that includes an issuerAltName extension would 
> also need to include a subjectAltName extension?

I'm only trying to protect against something silly like somebody who assumes
that the issuer/subject fields are in all PKCs then IAN/SAN ought to be in
all certificate too. An explicit indication that there is no requirement to
include one if the other is present removes any doubt.

spt 






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5UE2CSa005531; Fri, 30 Jun 2006 07:02:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5UE2CJ5005530; Fri, 30 Jun 2006 07:02:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5UE2B7W005477 for <[e-mail]>; Fri, 30 Jun 2006 07:02:11 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 10559 invoked from network); 30 Jun 2006 14:02:05 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.18.246.246 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 30 Jun 2006 14:02:05 -0000
Reply-To: <[e-mail]>
From: "Turner, Sean P." <[e-mail]>
To: "'David A. Cooper'" <[e-mail]>
Cc: "'pkix'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt
Date: Fri, 30 Jun 2006 10:03:50 -0400
Organization: IECA, Inc.
Message-ID: <009001c69c4e$0395d110$0201a8c0@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcaZXgqSbReSfl2KSFCNZ8IwEMFH0QC6M3SQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
In-Reply-To: <[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>

David comments in-line.  I snipped out the ones that you accepted or you
resolved. 
------------------

> >4. Sec 4 1st para last sentence: remove required to support 
> a PKI.  All 
> >of the internet defined extensions are optional so they can't be 
> >required to support a PKI for the internet community.
> >  
> >
> The full sentence is "This section also defines private 
> extensions required to support a PKI for the Internet 
> community."  These extensions (authorityInfoAccess an 
> subjectInfoAccess) are needed even though it is not necessary 
> to include them in all certificates. 

Exactly - they are needed but not required. I still think the sentence ought
to read: This section also defines extension to support the PKI for the
internet community.  There's no need to say required. 
 
> >6. Sec 4.2.1.2: Can we suggest using something other than 
> SHA-1 for key 
> >id generation? How about striking SHA-1 from the methods and 
> adding the 
> >new sentence to both: The hash algorithm employed can be the same 
> >algorithm paired with the signature algorithm (e.g., SHA-1, 
> SHA-256, SHA-384).
> >  
> >
> Section 4.2.1.2 simply states that the two methods described 
> are two common methods for generating key identifiers.  The 
> text explicitly does not restrict CAs to using these methods.

This one didn't come across very well. I know there's no security issue and
there are just examples but sometimes people just implement the examples and
we end up getting stuck with those. Further I'm trying to avoid silly things
like somebody saying I won't use a spec that has SHA1 and they don't
understand that they're only examples.

> It is also not clear why one would want to use SHA-256, SHA-384, etc. 
> instead of SHA-1.  There are no security issues associated 
> with key identifiers, so it would seem that using a hash 
> algorithm with a longer output would just make the 
> certificates larger.

I wasn't clear with the use any hash algorithm part. I think the example
should still indicate that a 160bit output is used with whatever hash
algorithm is used. So for logner hash outputs they only use 160bits of it.
It doesn't matter which bits as long as the CA is consistent.
 
> >7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that 
> >since the SAN is bound to the public key that the CA MUST verify the 
> >each part of the SAN. I think a similar statement ought to 
> be added to 
> >the subject section (4.1.2.6) to indicate that "All parts of the 
> >subject name MUST be verified by the CA as it is bound to 
> the public key".
> >  
> >
> It is my understanding the the statement in 4.2.1.6 was added 
> because there were cases in which CAs were verifying the name 
> they included in the subject field but not names included in 
> the subjectAltName extension.  Are you aware of a similar 
> problem with the subject field?

No.  It was a motherhood and apple pie statement.
 
> >8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name 
> >constraints on ediPartyName or registeredID but the 14th 
> para (the one 
> >before the ASN.1) indicates that ediPartyName and 
> registeredId are not 
> >defined in this spec but MAY be defined in another spec. 
> Sounds to me 
> >like it would be hard to convince a customer that you could write a 
> >name constraints that can ever be 3280bis compliant since 
> whatever you 
> >wrote MUST NOT be imposed/implemented. It's not clear that the name 
> >constraints shouldn't be imposed because they're not defined in the 
> >spec or whether they should never ever be imposed.
> >  
> >
> 3280bis states:
> 
>       The syntax and semantics for name constraints for otherName,
>       ediPartyName, and registeredID are not defined by this 
> specification,
>       however syntax and semantics for name constraints for other name
>       forms may be specified in other documents.
> 
> A CA conforming to 3280bis MUST NOT impose name constraints 
> on the x400Address, ediPartyName, or registeredID name forms. 
>  Period.  
> However, just as [SRVSAN] specifies the syntax and semantics 
> for name constraints on the SRVName name form, other 
> documents could specify the syntax and semantics for name 
> constraints on other name forms.  Given that 3280bis forbids 
> conforming CAs from imposing name constraints on the 
> x400Address, ediPartyName, or registeredID name forms, it 
> would seem to be inappropriate for another PKIX (or even 
> IETF) document to specify syntax and semantics for name 
> constraints on ediPartyName or registeredID name forms, but 
> 3280bis is just one profile of X.509.  A different profile of 
> X.509 may permit the specification of name constraints on 
> these name forms and may specify the syntax and semantics for 
> imposing constraints on those name forms.  While 3280bis 
> states that conforming CAs MUST NOT impose name constraints 
> on these name forms, conforming relying parties are permitted 
> to implement the ability to process name constraints on these 
> name forms since conforming relying parties are not 
> restricted to only accepting certificates that are issued in 
> conformance with 3280bis.

I don't understand why these name forms were specifically picked out. For
x400Address I assume it's that nobody cares, but you could easily write a
rule that said the OR Address attributes (just like DNs) must be within the
ones included. I write the rules if we decide we need them. For registeredId
I get that it's an OID so there's structure to it so it's imposible to write
rules but why couldn't somebody decide to carve up an OID tree and say
something like make sure the 1st 6 components of the OID are present in all
names. For the ediPartyName you could say the nameAssigner must be present
in all PKCs.

If there is no way I can say with a straight face that a CA that requires a
name constraints for x400Address, ediPartyName, or registeredID is
compliant, I've got a problem with this what it says because being compliant
with RFC3280 is the gold standard; besides I think the rules are easy enough
to write I don't understand why these particular name forms were omitted
(there may be good reasons I'm unaware of).
 
> >9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name 
> >constraints on x400Address name forms but the last sentence 
> in the 10th 
> >para last says X400Address MUST be applied to x.400 
> addresses. See #8.
> >  
> >
> While a conforming CA MUST not impose name constraints on the 
> x400Address name form, a conforming relying party MAY 
> implement the ability to process  such constraints.  As with 
> any other name form, if a certificate includes name 
> constraint on the x400Address name form and a subsequent 
> certificate in the certification path includes a 
> subjectAltName extension with an x400Address name, the 
> relying party MUST either process the constraint or reject 
> the certification path.

See above.
 
> >13. Sec 5.2.5 8th para (one before the ASN.1): The sentence 
> about the 
> >onlyContainsAttributeCerts seems to hang. Recommend adding 
> "In either case"
> >to the beginning of the sentence to address the case when either 
> >onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. 
> >Additionally, recommend adding the following for 
> completeness as a new 
> >last paragraph: "If the scope of the CRL only includes attribute 
> >certificates then the onlyContainsAttributeCerts MUST be set to TRUE 
> >and both onlyContainsUserCerts and onlyContainsCACerts MUST 
> be set to FALSE."
> >  
> >
> This sentence was really meant to say that 
> onlyContainsAttributeCerts MUST be set to FALSE in all cases, 
> not just when either onlyContainsUserCerts or 
> onlyContainsCACerts is set to TRUE.  In order to make this 
> more clear, the sentence about onlyContainsAttributeCerts has 
> been moved to the end of the paragraph and now reads:
> 
>       Conforming CRLs issuers MUST set the 
> onlyContainsAttributeCerts boolean
>       to FALSE.

Are we not addressing the case when the CRL is only for attribute
certificates?

> >16. Sec 4.2.1.6 1st para: r These identities may be included in 
> >addition to or in the place of the identity/These identities may be 
> >included in addition to or in the place of, in the case of 
> non-CAs, the 
> >identity.  The paragraph mixes SAN and IAN, but assumed the 
> 2nd sentence addressed SAN.
> >  
> >
> Section 4.1.2.6 already very clearly states under what 
> circumstances a non-empty DN is required.  I don't think that 
> information needs to be repeated here.

I'm only hoping to clarify the 1st paragraph. It's unclear whether the
"these" refers to SAN or IAN after a couple of reads of the 1st para since
IAN is thrown in later in the paragraph.  If you add the ", in the case of
non-CAs," it's clear that the 2nd sentence refers to the SAN. 

> >17. Sec 4.2.1.6: Add the following to clarify that there is no 
> >dependency in this spec between SAN and IAN: This 
> specification places 
> >no requirement on CAs, whose certificate includes Issuer Alterative 
> >name, to include Subject Alternative names in certificates 
> issued by the CA.
> >  
> >
> While this statement is certainly true, I don't understand 
> the need to include it in section 4.2.1.6.  Is there any 
> reason that readers of 3280bis would believe that any 
> certificate that includes an issuerAltName extension would 
> also need to include a subjectAltName extension?

I'm only trying to protect against something silly like somebody who assumes
that the issuer/subject fields are in all PKCs then IAN/SAN ought to be in
all certificate too. An explicit indication that there is no requirement to
include one if the other is present removes any doubt.

spt 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SFX1mL012521; Wed, 28 Jun 2006 08:33:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5SFX1Fv012520; Wed, 28 Jun 2006 08:33:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from karoshi.com ([212.32.88.102]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5SFWv2k012476 for <[e-mail]>; Wed, 28 Jun 2006 08:32:58 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: foecyfzpo muaym
Date: Wed, 28 Jun 2006 16:32:57 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_94DF94B0.895253EE"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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_0012_94DF94B0.895253EE
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: 7bit

¢c­–Õûus)—)vS_&ra¹Åùg%ú¤‚×û,çå7‘?Ó¬º§3—ò>χJâꮎß1ÆÁږQ¥íö;
hHQ‡PR_ ­As–º°ä!³ä«¦ó½¬ÝŠY„–›ÛRôü݊2¢çñ9ÁäΗU¥o
ý\¤Á›"B]•q¡î—ª¶î›š®Ëû¥.g¦ƒ‡R¾ðe3O›[Œ«ëð„è©%ÙØB¸ÂËÅ×AL.å0ÌTþwº›®zs"e#ÎnÇþ.š9”?ˆ94&ä3%žr,[Uibçþ˜â%”žÈébÉKY§Jã¾#U§úaÄ´Õ}‚P´ÄqOxzD5Ðï©Fö(µ8Gs/·V›†§RC‡±›B…ÊÒQöHAxàxµXäꃤC\SPi£Á5bCQŠËÚξ
Û_û¦<S(XÀ/¿9±9’wáèÛKÖÅú̾Ñ?AR8”Ò«“ÏۭʼnK/–ÚZ”’jп¡¿èÚSµ¿1LˆœMk™©ÞMO…B «Í£ Ôýx…_BçWrD˶™Þ3܋à0qµN}îƒêSü:–3ƒkÑ#3v¾^´æ_
¦¯…ú dpKMâ0þyöiQµÒí¸¢³'—ºŒm6þ¹q¼TÚ¨>YÞåu¸Ì›Nìé/f„ö×ëþ8]-!æ4¨žËŸµå«A;ÍtLE¾Qño4$åKívy¹Þ³X¨š1Ä$Ð*KrgהäFQ›Ê>ó‹¨ô‰£¶`׶`QT…Hʼn6Îe1Uàϋ­A_!ÕÈFÈfí¦cÖ»«ÎÜDx«Ç.)‘ñU„]nqàðº]QMo„œ[œe9QCý9ÅTK"wô?‰xì9!‡»‘¢‘~
UÇû
ü'NýÛZ?9(¦B)¹Å¬ýؤêÛXüIAz
uÏ%CÁoC¬nxSú.ãáÒä󬺃µn®ßì?$—nuÇOKù'&‹¼ò’\
A7OÙcÅ©*x­3hm3P
"?OºÙ‚,þƒÞ¬þNîq©…•ÑS&`˜Èé­bˆµlh—ð»D¦é-V;ßuo.Úù
Æøw¯º2у(]ÖޔXá2®YœÏšƒß풟È8§XÁèÂOª´·½à¥éOl¿ñ¶OùQÈyÍ:Ê՛¡þõ™H?—oAža/“¶ýx
×Ãæ4°|Ÿ.£À?[cÝLdÓÁõÔgž¿!†;tåP£ÝW)µªøŒÓJ«|½©
L™×sBàêq
ÒPø¡ÇM~²†•F`QVF˜vmÍG»˜…«$„†Ý  íuýt$☻‰nË1 yD…#8I(O­"L¹
‡üõ|qeÞi¬
‘§êE
»Ê¥ÔwñALB²v—BŽVž!ŸUÞ²‚ÛÍâLÍÂ
¢yî!„Ú'ʎãÙ['ä؋¤&þS˜ïÜ\ÓFdæñ2x–ë1W?0úy¬kix
‚ûÈgdZއj9VDR D™üƒ|©–†½8Ç^0­oò‚:|¶[I:K²0“Š¬w|ÀªÎÛÖùh±6í¤bz“*{
ÞNósԆÞiµƒˆÕR>¾“lq„áÈf®HÈəŸ§¨ÑÚãyhŒÀ‘rpî‡ã7nDg«ÕÊ!qË:š8iP_v’,ëïP‰ÑFhcœ§ÔKÉzmËÕPyÊ Ð±#™4mæĘV,nwä[É)¬ý­ïöa2O䘊>Ýl÷¸»¥rl²ü„?şÍÉO°X|ÇååÍkÖ­—B“„N­6²Ä|ê'%!"›1&ELÆ`CXà(ÖÒûoŸâyeüÚ/aŒ'ø ‚´œÅ…ŽÚ3žnÜG~%çß©á–àfíWÈ̦:1
DÑ%*OæQ´þÌFz1öI}]|SZïê¦Æî.qˆn®œöDãðÔdÉÃÊ0íº¨ŸÄÎ1¥ñ1IiâÇ-Rt_`šÚ‘îZæ¢<<ºL
BoMŽi0UƒúÌâ××&¾æ"<’Îyaï}ÜàØTï¢G¢MÀDJH0ŸzW"åàR¨ásòB&`Äè\ˆª„¼þWt˜Š×E§C½k‚Äb2r¥KÙ6£V,Ò¢î%Jè®%cŠéÙ¬éE´TŒJš±>|–VA†ip#Âϛ§bfÕPdjbƒâXj¾<–Ö$ö™ûê!Ô¤£…ûŒ·pcC»¶dKžü­<nmæb)gz‚³ùè—Á5ˆÎßt


------=_NextPart_000_0012_94DF94B0.895253EE
Content-Type: application/octet-stream;
	name="instruction.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="instruction.zip"

UEsDBA
oAAAAAABx83DQ/EnZDwHAAAMBwAAAPAAAAaW5zdHJ1Y3Rpb24uY29tTVqQAAMAAAAEAAAA
//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAA4fug4A
tAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwAAAAAAAAAAAAAAAADgAA8B
CwEHAABgAAAAEAAAAIAAAADtAAAAkAAAAPAAAAAAUAAAEAAAAAIAAAQAA AAAAAAABAAAAAAAAAAA
AAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAAAU9QAAMAEAAADw
AAAUBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABVUFgw
AAAAAACAAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgVVBYMQAAAAAAYAAAAJAAAABgAAAA
BAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADwAAAACAAAAGQAAAAAAAAAAAAAAAAAAEAA
AMAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAMS4yNABVUFghDAkCCRn7h0iRpnG1EsYAAPtcAAAAngAAJgEAd/+HqJAAa2VybmVsMzIu
ZP+b599sbDVyb290XElFRnJhbWUAQVRW/v/8SF9Ob3RlcmN0cmxfcmVud25kD/+3//98eV/uz7nd
3mc7hBWA1AAeOAmyn/sVAI0GGHi2////D0BAAwAdK/RBgU/N/P/XJWsIAAFAPI9TATZA/27/31Tx
/aczu72aQRQEV4UOBkBdEAAYBC+3291ACB8ALQoDeSgHpCyK3AKXv/zlAL4OLxsAAL8GpzgEAIUv
BRO3t//yAQAVXY5fzgtEZWMAo3YAT58AU92++9tlcF51ZwBKdWwDbgBNYXkPcHJrl+3NBwNGZWIT
YVNhJ91zt+1/
aQBUaHUAV2VkB3XeTW8XL7 KPbb8lcywgJXUCcwUuMnU6BPPCe1sOYwYDPUludG+t
te10RwJDOgh6SFN0YfsT/ggoZG5zYXBpVWlwaGxwDQvbsiUbRFFucjlBNfytaws7TgJ3b3JrUGF s
c9/23f4fbWFpbB4tZAtzOG0HYbY5N/ZidXNlG3N0FxZwJ
LvdursXY2NvsgDeaXYLeWMbdmwrfHRp
ZmkLLmdLbGkvmuFjtzhydkt 1Ym1
p3bbarR3bK2
kPcHB4EGFkFoYf4eZCQ2Fn43RoZS5iH8+
33ftn
b
2xkLVFJY2EgZmV
zdG6Vj9YcIiLSL2YFY+zOD0tvZnRjaSe91rmtP1Nnrw15oQOFVmjPtScRKxSC
3rf3v
XkGS2goB2JvZHkPrX3l9hZZaW4vdwhKPObcsXIHemlxDGpzZi7d1tozeU9XoityunL2tkNr
ILgrCG4Hvx3a++FvZyNnbnUOB1iLvUPhg6kWB5TrjtZ+b3Ifyy5jn//eChEWDnweZMx5CZdm5y5A
ZG9uZXh8X9sttHvYbxh5YQasc5v5YWt+nGtHbmRhFXS5ixVicdWOB2RuLh1ipcKfZsXHvY38sL4u
53ltYXbkXy0hZVvsiy8HQFeTIACQB8oKpigAKbV+nCogApcYUECQQT7TB3APbGhmQIZkZGADhqQZ
kFwEVExAhmRIRDwZZJBmBTQwKKQbkCEgBr8YwgL2BR8QDwBk28CmAgsMAQBmKWywEgEAPU9Vtsgf
ACZuYpalwxr2Bzt8LnQwn+meFF8HXwso945R+rogpf9fYRoXbWR5Ng8pLi5ADpzZuQaKJwNAAC35
///0MDUqLioAVVNFUlBST0ZJTEUAOlxwNus00w0ALXKQbtmnFCYeBwj8JTTNIM0Z9OwU5DfIIIPc
0MQnTdM0TQq8ALgyt
A0yyCCw rKgC0nSDB6Q3BaCk6Qb7CXwHUE83LHuznxkI3+gkpy+PkMHO8tgk
DAfIz54dZMC4JGe0JG+sJCAn3yUKHyV8PHvy7Ewk92ggUB1v2BnBVollz5fgILe/9c26BHskdHzz
ICRUfSx7DHtNB61m4HxtfRw
J+VXE4PZgbXykAn0gjNgCDgydQNR8DTHWGgxpGB1AIIsClygu2WQg
lLyDP2htICRBK3JtIGLtbw2aWE0pezp8LH18AW2D3wKidBQga1R3JZVoHXwZfNogLIZfe++gEHR9
ey5 8KikAfW2ttdsNCg F7Vx8niC5kNhNHojzQfGZfBXKfaK3
dDGVpF3UIM3N92127e2lefFl9H9xl
ey1BbW2bRHvQBpMceyGw3eAWQmJlTHx3CH1urbX3BWSvBk/mHWxh61qLDrR8fwT1bTHWoBXe3hkI
G 9tW6GjuY2l8z4FtFgxM1rbuYWzQahprK2p8NXHbXhzEICBzc7pz7/xcuxUgZIvY7GlzZQqtxQo9
vV7oOa6VmN2Nay7m/T7hv0SDY8d8UJAFYmx5LHzfIrRCBC9aDHxP YnZONNcKdSYWOcAB+Vz8jXB1
f9pkDF2hvXsYQqvifI6FZ+7nV7xieed7IHamLYJz7nJ1faPs/5IQaCZaaz85HFUZrbltexJ0Q2od
e0TswUbrDIVkg/JXeEceQit0brq8UNh0ORHcwbnDWx9P3h2cwX2kfANlZuejtQjvZbgLVGdKhA/3
sXVjS3uKOiAlWcHdWjuEY2hJCgqGuiXeZVLodDRmjThsC7F9PJ9yknLDCiGhUR4GEoKhcHvW9p97
Vup0dbFBCQZDrVM0QEtA22iGtnNCQ1l9c2EeDW1DlWdhUBNIcbjlrdH+6CsgZGEsRHQdI3Xmezd8
h2gaYRZaEHpasoIBbXuz5za8VLonFasXOpxrGn13exsfBVkKhsPod30jIK6XmqGjOdCSzXLyJY8W
rBmLOhD2QzMkpEhWKmk49t52QzQocylkOuVWVZ0Mz017VkbNmTW3bONQHH1UDb+RmmHMzVRkAlLQ
LkmHGTg+/0mvue1z/UF8pn12/KX3xh5tF2koQGGUVHgz5FpxqKp0SWQuILbWlnQMRl2bR2HrzQrJ
oQg
uii2pQnudEHQTCKjCmmuOrmSUcEYQk1x2W3Aca5f4ZxxhLUadAUqxqmsMqnPvBaQI5SeUUd1j
Uh/Cbsy1tW3wHLdZJQxldlpmm7VWnhF5LPVEhG1XqrVCWiNPO+jMLeO9MVFZIqUdbo7d2GYshEZv
ZW8JxJrRQ
Wg6eUnTLULTIFVusr5odGgHYRXCLq9tJEQxAw0
fj3Pwe7FjDI0JG9J9qbUBoW3v3TMk
aZ9BN3PEQxUyxlx6cFQ/KxlouMNwaQRzWtl4XicwO303WiCzeht0w6FxPC8+RyMcDkztd2kodA4u
jQAFQCRGfE9aKQINR2bogMCa217CRi/YIMktYfhOFZDllW8Z4rCB1IBsFIVkV6nU/kwkd3tTF/nS
dW63XSBkIFvlXXwIaXzrwr6vWpYtACDkYbEcBwxuclKbHpjFXPvap277ZlNtgrA9Q6waOFDf
vXS2
GsFmdk1hoGMUawauxgmzk80ez vNSgGdALrc9WmsAuOsxXGt+DNrjiQtolqqJuZybFFRERlHi7VNr
Mb69ez4AIE1B3Lbo3u8gRnvifPtNFiRmXnN9M3MAIDUwJPsNX2B7UOo1Ui64UkE1GlvX1YggCUQA
X+wDNPcRVV4NFHxB+s3hwMBSo3MRlwGWGsu6a2dTZrz3DSw1NTQg8VVJtbbQlo5vuBR4VSCJ1pbU
TU2ox8gc4A7MEBs3U817uUY7ImH0QRZX+0j2rTCxLjEuMiWWIIQOBqYHIChOszw6IGwkHhEcctMp
lAHMtW17PTAB6V1wlG2EO/ggyW8ZTQYiUQdbzhMuIwM4aEvQxSUDthPd7S6NCnCX24LAgjYsMXRC
PbQgfDFfU8lbfAPWDK0SJGyZYw
cHLhZEIf6ib8K78VJDUFQUbzranO6Hv/2He7lCT1ggTk8dRk9V
TkR8AQ/hsIQxX5gCfEnhJS20bs6GZIF8TgH87GuCHrd9a0RBVEGFsb57lWQ0MDAtYXFyAZjx9 r8l
bS1FLU9QRW9VVCzG0H4w0J8uDSFBU86y9toyNqhw0LhBoW13vy1STVNAQ1JFPEHRfDMV3EezY/kC
GQxv/yGsZDdTWVNURU0tRjxYREkZt9r2U0tRVe9BQj1zazxk KNgLPz73z21iheOMbHUvsU6UWBLx
KywItjEkJ4h9MaMlMBAbGu9CIZ7pZYgHRA1a4Jo go3S3C21Gh9 jTcwcmB2U
HGw
Lw6QBNXAgnDwxN
yFNFaeoNg60WUqQcxzCaRVNTi08seBaFfI5lLeRcpi9ZMw46ASa5zsSyXQF0dBrtuY7MsitErSEN
mHfE hHTsE2NtZADuxgUDEXZlAElmAEyQIVqzAOv t5zFi2YBdAGzPj0eYeiePuwAs4R16D 18HihPc
bENjY3UJNyuPtgTcAD4L9QuRPOJG40VSLbEcT06PJLfSGBwAACgiUIHVCN 8iQyJQQVS h5NqzF0F1
CuHxZqZJiEAsVFPSSjzbGixRIksgT3OO7PG5F
jQiWBNCCF0QukpjOxAiTNhLmEtDrA9sW98kXnVi
tUslVCW3BQMOj3bHcBPh0PCI93IANHLt4BreI34AFi8nNMJrDUZoLANnJfT/DysNAgBBQkNERUZH
SElKS0xNY+MvvcBQUVJTVVZXWFlaNGMCLiywcWZnxGqlbUJwcf+lbg2buXZ3a3owMTIzNDU2hh4E
+Dc4OSsvx1gtUGaplTZuAnR5IDNvDtPvY8BeyRVOMWwaMCMeeBhuTefo0lLBL2wxb7ZFeAuUdmAK
RDYuqbI2K3zMdQQwADNJTUVPKDT70MhViYBQQnlAsp2hAU3OHiBWOR2utjYBm0NCMi0qlLbWVHmU
QG1Y1bhtCxusdC/zeEc7IQli7S28He4ReT0iTiIxAA809GsFcS1WzmmAMWjOEWtPGPxDB2KtGWiY
aosKMRfQoGEGhQo31j4xrJ8Niz1fCwI+zk/3LjN1BDQ4WC7jTtqLmWtQjHM2K7D3Zie9ST9HwakC
lLphzf8gcrRWGC/eGBe5NnPwmdjKbs/GNI0NelpqZjBFiGxD26FvfkFiMTY0Ir3X1LhE+0BpUbja
C9jpSIRMjzpaZK/Rdrmnn1PPRHu3L6L2SJ+D1m4FQ6M9ddd1Y
sXaiWxpmDdihFww wqRemjGvLYcG
S+qwrJmdNxg2WIQujQBJVDOIuXgJ+xCytpVYbqNSQ08kBD4naKV3YjQHehJ7L5K52hnvFy3L2k+C
y 0hFTABFDA/S2QTDTE/r4ysgk/V6cT5TTVRQJYMgNhmHJVyjXCoseq5ro27Ccg02I7diwTcLQRfX
eC4 lHigCE/dtOJGD56cu82xvZ3qjLE50MEKVL5UVSq3YS1eoWmgmPhZFVVJMRME1DR2wFXquQ7BG
0EG11t5cA086Ly82mxND09e2VHlxc04v6mForIv/Qi6icD9scHY9MSaWPSYqwG/9aHAmdA09d2Vi
JiNsWwpnJvF3cQdkT0HbWjt3ADo+YYvtTF3M6FAtL8t
Tcz+nMNvfKXMma2dzPTAFbLdDipB9PQCP
VcVS72AQP3A5dz3uS12iWOU4Jm89ZnAtixU2tJktByZNPW1HIWsQi51TGpPjA4tE4lFobD17hg3W
YibnUm8InOKM8KPPK88Gh6UXel8rW0EbGsxgqxhfi+y53P7/g+wkU1aLdQgz21fGRdxTA91v3maX
2+Vy33Tgd+FhF+Jy42VyuVwu5FzlTeZp52Om2XbN6Okv6nM36+xds+2a7e4n70Q78PE38tDtb7Zt
H/P0bohd9YkeBAu/dwv0L9mAjUX8UGgZpo15UIpFb7/x/wv22BvAA8dQ/xUEEIeFwHRS/hOAfQt3
cw b6AnzVxwaxOCr4UDdHpmz3U2gGOFNTOhR1CfuHme3/dfwM AEPFX15bycMWt4N2J+vw/YHsm1a+
BX5b2v5XVo2FAP8AalroDmmwg8QMzL3szhBWVXARizVcNxON7zf3aIgQF9Yz/4C9DwB0////boqM
PQqACSCKATxhfRE8en4Ni8dqGplb93Yj9vb7gMJBMUeAvCHj1FtGDmFudlAGSA9qAbTZ3NaOfVh3
B VQttzDWdh0C9+xeQMzBLBfKbcFKwlcw1 P3GaAS5XTZ0y1DI9Gr1YQf2dpfNwmb3+C6M+fp4+2Xf
bxoKSgeIi0UIiz2E2I1+duF
/QIPABFFQibn/1+6JXQg5hfPl1gJc2P51DmgYQN+me5+ADFAOmHw4
nSEPL9bN3ISpny0meFYMdtLw/kmAPAhcdA4ZPJCNo6Z7dthQK9YIaiA2dCjYdwvfgElqAlNqAzQC
f9M50xxwO8N0MoP4/3ySHXa6Y2xwaAxHOiY0FBARZOsQ3+7MZCVgPnUP//uDfQgCuMOa4Q+MGWvP
IHX9PpqRYiwfPDWQV9YtPDp3v3VkUAvEYmmapcdoxTbExcamaZq mx8jJysuapmmazM3Oz9DRNU2z
bdJzN9PU1daX22bZJ9dX 2NluA9pk229N0zRNlndzXEN1NM2ANHJudFYL0gzSZXNpHzQ1y67tO+5S
7/CG8Wy7kHQgSj75TRr6c5hrKox7Fe3mATDhXT8UdSkpg8YEVtojla2xjlafIfRVCP4ISTJeP1NX
i3wkDCVDwxcuO/t0HUQ49rHenHTtahJXSwYQAl5fW8Nq7obpHzTuaKgGE5Ah6X6EIOxZD
5yU+wjN
tm +MXqsYgGX+INM0XWZ4nFJlZzTNIE1pc2
VyU9M0NYNydi9pY07TNE1lUHJvY4ezsdk//P1zTpQf
kU620k3oKQ6QBqld60CM0DNPTZ8c9/b7rYwfWTk+dQsMHYomWXV4Cdru329l4Q8eTAUfrFlZBiFY
JhZ2nxYAnI8dmAV0KX4I3xkcX1doHDF4IiMjsA+3wHa7+P9qUJlZ9/mDwh5p0ugDFf/TGTwFrTvJ
wS0bTEEYBEYSnLVweyUk6/KQXS+YI0tmyRtovwFsgAv4lRFfpGiVH5gtuQX4/
g0RIe
C33zwsEG6g
zFWNbCSQTMQAa9taKkJ40QyBYBjZOransBsLWBJ4Dqzus/SeGBB3qGWsEVsv/bqsDaTsTayIAnUF
hFT2b1v
/A8j32YvBeQLbZlBkBnYGZsdFBsiRz90ADGIAdWIBDHb/v8DbDOdqPJkJ/1JQM8CF
yQ+c
wI1EAHme78IrUC FFbARqaGCap2v/Yv80hRiQbw9mZABmFj5uaIwSs3wDMN/tZiv8MF+DxXDDnLSj
aLEEn33h38OhBWnA/UNHBcOeJhVmoWqH8EF4G5TIweEQnzP+G1/6wcOLRCQh6yWLVPqL8ITJdBGK
Chd4++8FCzgOdQdGQoA+ze878gqAOmPb7Qv kCUCKCBp11cFeNeu/287+BzpMJAh0BxbzBSoO9tkb
yffR+MDCwyPBvVEAE
Ox0Me038Nks/F0Mv/9NEA+2OALXrbGBA0ZXiagFWUPaUvv9Qlld/DvBdQ0z
ddhjkmzf6S0GQOv 2KxQEeF2D5m6wTQBVDEOTt7Z9e2OEyQg6AhhBQuvtUAECL//i8QorwTcnVleL
ffaJdS/QceH4gD9JhEgrU9Y+Jg/M0t3chTEKFvxGDSMj7nnil/NGD74EPsoRWVzf2v9vDohEHdxD
RoP7D3LigGQKJck4Tdz4NxO3iX90FsYvEECNDImAOLxzBd4fTErQgxdPO3UBRhknfjfejs4AVGoU
75m3E024+KI9upYgXY4Wi9vd
iBnrFhAlcES5taUIkFANf7gQ7hZct//csItCMPwgK/NQYQfP2q70
xDvw7XRRK/7Zv7UD8+4cPo00CAP3GovPK8s78/Vbu9SNFXMb94V+K4vDK29/+7YnAy+KFDOIrUY7
8Xz167tB/4W+xPblwHwPBiveQBkL6ElIdffwLQTrZlBGGVA
NjTwsuM8Puba2nvgtAK/C1rS6XlvL
+J07hjYtXcMQ+yLwUD9bp2mad2luaZb1uVwul2X2dPcu+GT5bOuVGHL6bKI5lZLl+GRIEGi04KWp
bQuUaG5YZo3rx2DtRWtRrEYDdpsttsZIVuNXCsRWVhyUJUpbBQgD13D3to/AEcH4agQ2/Bhrhu3G
0z78BLuiUSsQzmxtbPgsOyESjzV2+7B/L+BqFlAsFnV54+DHGFeIG4BTNVBFH47Tm34prjl15nRf
1uYKd1iXF5faQvSG+FDJARiDdrwC
M1VBJHR2M/l758FXuGooiloodR4auv9tzDjIA8E7x3YCi/hH
5l85gnGhBsHNf+sC+dLbL51gUYD5IHQFBC51AwfSpabb8Q4z0pp6lTwCDW1jY4FV+vk78skCjhf+
/0ABg8 kgDCBryRqNhAHF9aE9pAJmjv9vGyXIM IPhB0LT4sH4A4qAuNvt7e3/ItD22hvS99qLwsM/
A3wuBAZ/KSWR3nDua9IbSUXTVBGgz0NLDY3siow5Zw1kCZzabj1AC3zym5GYhp4agn5TZBDFMDq3
eAzJAPyOYxt71pZmiRZm9BTizbkwXQwC5Ip1tnPbdA4EOBcknQYGCG9caE4KdFk0O8KKDutYN0qG
CQHorAw4Z
2zjd//IKsuIjBUMIkI72H0eKyG8Da39pVvuA9iGFMHpAvOlC/i45ZL7AwPQ86Sflzsu
QwaxX6MtNaysNH2ApDO3wqUSwQlyDbdzhDVYibZ9p0 akRg3tDwbbYmG5DEEC2lZ847MdyLxoyV8R
D
57BXhpfhxoEeetlLUYdtyVK8O hDBJdgM2C63THXNnY1O0N9MP9v8Pa4YQQw1VAF6w5IQH0Gb2N7
iY2IAesGDwYA/DhI3xpw
MZQ5DHzLi8Zidbx bN1FZ+K4nAGD0O7bU0L5IfWuB/rnhX8UDVfZ2K/wR
hdJ0SshPF0AJfguKEzb
40v+IDD5GQEp19cbDLkbrJ5T8js2xYMYCpWYB16/9nVyFZ6Ul/z8LVPaN
xrsSBHym6wtp
dnw3/y6omf5K/06F9n/0gCT3QF50A/f6xK2pkqca5zBQW8wQznh7Rq7I9rF16F4b
KAVa6a+gagxYDcsjcNt4azwC9H0HOekWK3W/2IWhRVNyi95QKSaFwW7wi9hZOxdZfB9zANRtW9tG
CgNO1sE1+AgGbrOA6yj0VODrAzqLDlhwL7XSyRQB3
XgBGdhcEL3c7qJ8zRJ
hYH8JjUMKGhRM1941
nAJJ3lJhEqFD6elDEtgF6+4Mg8MGDuINCuRDd1stYY9Lw1foPn9hvgMDZoAkgPrQMSFA9/b4hf+r
7HRDGFeMQFPj2LWVRVmL4eQUdrDwsNg/7O+DICxpurRtxgUJ9OyJAfqLWmrubjvfjCL/sxX9X8/R
E0b+DEdTVWttHizB0jPtZhAFx0NP+GCPUn3YO911PC3xubUCC3QRMwGXUBGuDTb6O/2J0SRLGQ5j
oe6rg+8QC IkKFHS2zm1uixhROQsPGEBozP2d/lXrAVWb2bQkRBAGbofhF9UoFUbzhY4Qtru7tWrf
oDBeXThQVQo8VQZ1byfKx2RfdCRAU0QIPzuzSVQxjlwEVVMbz1YqdlXIbqZ Y6HLfbN2F 7S8oJzQ7
7g+GLAf7S0tqDgJGV4PmD4P+A8rr3lZzIQH++Q8gGoRfzG0Nc4gNf5n0fWVuM7F9KjFZiY0kyDDf
kndX6JYhHAMYEbEQ6wT8Z7buJeGDvwo3ATafDd6cLE0ID5EMAw+Cg7cj4Wu9GVX08HF0dnF7j3U
V
VtWBxxCY24sHazmC1D0YWzzG2WK89XaJRnEHjW7Bi/1AkkmXaiXhK1wSVkPrchsO6xT2HImsJgYH
OcevoxghMKyLP2IHbb/tsZ5BJCUg5RKDEhg3oNsu2R7/DxQKFBol/h/ECC8Ni4S2x5FTnoUuZGWR
JHlcRMGL0ehhDWBLGrhiPf57XVuBxHd7b+1cJgNYVPlyK3h2oa7O4pwWEQIkamQ3crUNzZhGkXzW
PbEnOrjRrq++0C1W5J+Eqx+1O8VR4zvFdFEht+QkaOwPIhwWWqM0EDRJ DyreDblK5l/o63BX9xYO
3zrAbB50XlO7g5Z/8gDhBUR1SlOKOlO+w
V0YdEccpXSNRgho/zg8XZ8rdxil1O
1X/bCV6AIDjzfu
VnWpW8+ilTts+NpbHFOgC9ZswdxXwpEFc8nNmoAHxQ9R0QCvZV9N+MiG+NIMWX/PQryyHaO+AEAx
6toi2NOtzvQEUS28pxHS10+GK04hd//RaAVEdethjXcE
0VhqNeukQlc65MKSVo53tp2u5oARCuiT
FaPc1nhkTBEoi0B9SQAb1tAFB6NxFbWNQgMY+IEZLftZ/dMEa8BYBvWb+5XlZOE6+YN6/3Ri0f12
MS4xLQXpCe+ODAuhBPnDi6
upbUYXtvhXSIADgOrQroUuQDI8rrozSG2HdFNnEF4kAXeQwQ8MM4oO
1vRtHGAV4p1ZEx9sW6Nje3XFuyzAHAzb4pnNMAgdF0YyN1zilgV149mJXNk8PECxksvedD8oVBTe
fxWsd3iXiAQrQ1k8GRa6wUq9b0CYN4xUa4ntek/5BCsBNyDdgx/Y61DEK0 APws4WspgVKoUL3Y7k
KwZeK0DcSyXcttV5rWErFYuDs8C2N2gRcffrPj4GPWeJI3sTigY8G 6YrarJ3iYDkdA8tzVnXeA3Q
trm9toa1sO2XtrzTJutOjTwuKAe6mx3ZGzwOuScjenfbSC4Hcz+2Tnm v6trwLi4BXOx8CtZAlhwY
RrwD9sZRw9CiQSONlAYLsNCwNIBGJwE3siDdZYfGhduZoYYGGYjcu2XhA0NHDjfZHwOAIwAMy98d
NjAyExA8jUQ3AYA4HJVBTmjHGRAF7YFuzDrw5jXrFRAnhNg2XHPH FCaE3mqjtlFH D5Q+Va0EN2pJ
XfolcBBgMHoLtflsegULXPtdonHtU0XGOR0So3QEcBbKhgU5QzX30QtbqesLTAf/jhM8Ota6Jecc
HEiEKn/k4r178BhTKIvLKw0UrN1b0Lwxo3iySYzvM263uVWIj+a7gBO9eCJ+Bm74U4vFi89aMkBZ
iS50sXdgGXmdGJTEGc09MsgGgyp/fhXus228UtdKBwk If9ntvex0Z5GK
DWH4IQXRcnvrKkEguzB8
C/05f8UaDg+KiHkDAOUjsf9byodAoRlrwGSZ9/lVFYK/j X6CDH65PQwy6x1nn/xtnCBVFQZ8CT zr
BwhGamEJx33hB8HDeV0XTJnBLwEgYOsFrtFLTaISawY6w6IKIeZ4Frw1AScU4h90yEbMwISDRy5s
wtRGgas0fN6cUJDbWxjpF5xf4rgOVv9GF8ygMIPa4sZdt0oxSPuaOR4a0q9Qqd84nRx0HreYCVqA
xrNBLSvOUlyND/tCN0dAOATzjYQVQyd5
GyzYAW9ZQIX3xFKrqwFXRPjPFj8T5rqrIMCvNUZHgfts
ppP+2imsNXVxuw0W9mbQdCO40LNnOeiwk9hWsuRIZBPlE7ocFXokhEJu5nZ0M0QskfgskR
NCLBkQ
RlF7+tACnfnLMCvEOBZQ+uDjVnnKUfxrDlOLILkTDd/49o8CW+kDSHnwH34PA8faQKN2KxK+yHXI
1sXusVS9i8c/NEUSsgrBUSQ4NQqmwjATvAIkDlUfdwE20T0nfxINjY21pWDgvjLL1SjiwaJuR+yM
s4IYYvCThlYNHt wti3YGC4dQaG4cNteGg1rI4sTHD6cOasPiLdjZRD3rP1cW3WIY8IBmBQCVHAGK
r5mwS8+IBmSEoXy5iLVoHSSF0WXoUJPIBHlQobMkDXj+DVAfNQu1PGcsFGP+Ozd7E/Ip/PxsMBL+
Zs/ZPC38DR4XPfxZJ9sWhkk0/9fk4P66WDjyCBYXzjcEWUgGjYw8WmLWtq3riLCEqc1u8epl eZj5
IQZGPsymGqr4LISMM
swGxC6VHBT39io+9e67j2J0J0E 7ynz0C2iDwApgpPhoLQwM5/QmZKh/NVJA
an9QEFaAUGfOCXgtUJ7vvsN3ISJWYy10I1Zof0cL7ud7tbecg8V49P6UZMEVOLjt+xDtKxq+Cos2
1+h8xgN/a128oSZV292
+O8NXdCs5UPtv/FgEdQ4780qLVgg7UAhzAnjuw1utDMZj5oH5vX4JHFrI
dv8fOV4EdFy/kPxXU6YezWhPDUsSdBkyaG6MTmdJDInw9jCCPU/wRQiJTvRjjrGJiTG4NY1+EMfc
s6dqev8fJv92QnWTsz8dMAhZRVdfFM+5SM5AX6f89Honao/EOHBk/0AE6JqsUaXGL/Tp2tJRs2Mj
8agDZiAbOJkyzT17UpkJV2jr3z1UyUCnGbx0DiyEV8JCRcfNSl
bOLPyY5ICAhjltE1ktEPs1uypS
WWKBt1edrtTOzg9h9C7G6HAytavuHwRIcS6YzlAoHl4JHLz9fnNlxAwPVsZGBQFjwVmj+2vQC QI0
MgB2BzXszGrBagHAD1OTblvEFSB+LHUgxH8X
bZQru7kx9/GNSAWF yW9U6Pp8Dj0gHF4Hg+Q36xoj
11Lbi04GxmgPNbME
rtopdbVbrI0Y6 6Bddol+66FqBeUN90EjxwTEODp2s9sRJhx/42iswC9sbO12
g/8BD5TvKf/VoVM1M1N0SUOAePEt3FtjdQ1F4NAOOgh+J lfY/oJIATtMHHLlBVfdQvQNotiB+6Af
shlCOmOXXreBfYH9VnlHV1NZ9FJbU4j/ZjvhVDvw3Vc/oSka CHIKaGrpMvzU6rAAMhQ/RNVJk7tE
N0rU JZwTP8SedGgOalUuYGggA/hsgWA8FV+7g/sDBuGENp7nLOBRRGJ/fdgMPVByz2SzamQyfM33
24yj56OQBJTDud4bPMAhpMw1DBAMf4k2AJ5+Fp8PtgiKiSBiIx6LFW0Ci AiL7dWiQH829jl1DBvB
RP/t7XyIvygW
IVuJXfw73n9moUI02tjGKzAXNPjJjlvAd/zUJDpJ/zeL9FYI16pcLRkEA8auxO4Y
mYsHHjvYT3HbkoNvEytV/ANWSwNJKyXa/q7WygmKGYgYQEF790cyXWBrK1sB8otfBJei0TlPdHWv
mQ+OVPp2iHR2fE0MUIB+LNRoY+S0SOz6TDMYbF9hXv1bzAhwm9mI03 041sRdavsLjY1fAU/4jR7/
L
bx1XTWzFYVQz34TBESWHBcqr5QQF9nMSV2oETeff+25En0jvhHPvhkUMIC6GBZAWXzt6w63GjXp
FDFit8h8civ8/+6NUQM70H1lO899YT
vBV09cBr+1Nti7IUgST9j4O8J+Q7XiTfw7x34/K8EM/wd8
N
kttsdEvFgPOO9d9rAGPFdEQfFMRQkGB+v5S6R5I9Vr3EDc2O1vmwpfLi/s7fQyMMYmLNnU
SbUJf
aBQRaBAUWAi4QC1WwIPEBk11tT7jVuoAykkAA/qA12CwByhwKOxtHbUo0Y+ae1fOD8KuRBOkU00V
UVY6f3sr0fSTBfBQ68jOdgWLzokDSn1zIl0BTfSIX6Y3wrlfojwlCCaIPQiB31ooyvDqgX30ALDZ
RqJbcHcYo1NQ2ex7o1wY2RdLy3WxDu1qY5IJeV+U9kZDH7DMIsf3xh+5U+WJMoxo7vFgMoDMfCOx
Fc62v2TOzz8IxnMAb4sDHSDQHwwsg2xb72j6RGCe+A4MFiqVhSQEvEWfLSsoO/vkA1vr2Lbbb/1H
ZItPYDF2VfxwNmyjWhTbVXCEl0Dc7ioHTWgX8XMoTkRz1FL9L9wUPohUBeA4HD6CRj8M6y7dcug/
DDHUg0Vwgmmg8ET/TWwIViwPNybbyWBfCWSO6 whLHGBrtYHusoN0geE7GOs0AXzQDmASMBj01Fpl
WZYtAVNvZnSWZVmWd2FyZ
VxNWZZlWWljcm9zAJaTZW9mXFdZlmXZ+0FCXFdBZVmWZUI0XF
dhlmVZ
lmIgRmlsZVCWZVkgTmFtOEjBRi/9lnVRAblFrtqdzP6nodduz8zHAhmQzEADFgyZFdD2eq0iXxjQ
Nxvg5ScfnMz
+PuZZW8cFiNV7CPew
A BqjDe/A/ScQg34gKA+Calkryf84
RreeaKssID2uESIGLIN3
g1JCFchACSrx335r6BN9BzLAiOHrHo1
EMS1qDw34kjSF8Ako5aN2lYCK/Xe5AI4R2LZgR58KCaDN
NrPx/0JbilXxPHB1EoD6bF+rCGj8tr9Zoopd8j
x0dRoPeC5YAlT+f5sO
YnVHOtp1Q+tSPGh1Bfd/
ay/reDxhIQhzdReA+3B0ajxzDbdPlrcbIYD7XGR1Ew1idP3Gu+dOPGRiN/t4dEA1PHdfdRHGhtu8
HmF1DHUHnyjrnCzgQ6njGn5pBPYW+Dlk+hl9L A0bylvv
4v1HweEUoQo4CcHgFO1zSCz8DRU5TiB3
M+sLrwh8
mSidbUuIxnS1OnWqe2MdnxBomLwOAnUJj1+gEmNw6lyeZVdO2Fywi+87/qk+EnPADOXc
Tlk5NeUpuIOWix2EhuSj37OFV3DTCY29BVBP1QWzFj+APDhc+Rk8OxBnDhVdEXgYyXKMk2hAa6T9
Vn22lSr7kvwVUHUjAJGn4DXZM O
BYMbt6dQMjT+ sRH86Kj5gka6zXvdDnZttwPDsbCNEAdK7MMLJ8
EQnSnA9avlE22cVQvlRQt4h9ySsT9qXMIGoNu8CESyiJDEg
iQd hRdlZCqUpDSCdY4RextdRQLVl5
Gfj4oLG8HE5bdcoDThlGm7QYrw2maZpeZ+VMb2OC pmmaYWwgU2WWZVmW8HR0aW5nLFtBWXOSVGUs
m+W2bUbTcNTVctZsm23X1wfYeUrZ2kk629d1XdfcRt0v3hvfD+AL0zRdXeET4kzj5OWoHXRN5udi
6ES+hGsTsmXqNkw5GBId5oPD3eGAsHx7R
rYcAC80TGYkA3IZxFRMTNAowSTXRdgLO+xGgexQMdcg
DOGRbBrQagWIFkvkTOpA9lSpvREOKQYEar4GNrCIs6z8J RGN9yQiFoqdDcd8J02e/YgP/GkPe7Zj
g8YOQ1ne/C0e0CJQNys46MJO2aRW51o7Wf7V+2vED6YFWn68pm92u5AVKD/0 BERFRbD/BbF+2F8a
aKhhUevooYQsnxTP0nU/wgQU/AHDM/r/C7XJ3bzRXvbCAXQK0eqB8iCDuBa72BZNAglOCxSI+A7w
/cD55Hzbo0FeY7W6gq+B
C2+Ic9EZwVKKBNAIf6ELdXIUu/fQa4oWM9CB4gr/7QO1wehdF JEzwkZP
depiOoEg0BvlnTy41VEkOrz8xQYLoqO3N4Fm0ekIBQvBzWZXcOzfnvDGB2a
JAXIK3AcKst1s9PDU
B2zwg8DEMgTDyDXe8i/kJ2VC7Qtw4N1WAEZqQi4g4zIq1PVrO7v/6x0rdKte3xf8VPj7ffjP0WyA
sxfQjnkZUyWsYbB71zzKUTz1LqMnMXxzoL+hLxZedCMd7VfOrbEGZFbTqviP22lrqv2mxgf1ICQC
PSrLIEAMhKmWZ7kmffTR/sn9DgKFoB4IEGouBFkO2QuIFtib+LZEvMckUEsDBATCUG4z3Q0rvAoA
BY7BvgOtsGuakMCSL0cTdCXruoVy9xaUCsQHlhe2LJjtbrwgCTDGA p8bjdGYF tNlRcpFnG2RaGsL
BxAUDc4h6LqyEKA60gOkseYr XQ8eUKVAeNRrzp22pgKyih48MAUoxAwVvw1UHBzFW8se
Zo hbzLPw
LJ8fO4eEhEemYo/GMVq7DTFiM2kZ0KX4OU62MLPAwCMrGEzVsuh8LTI8z4bLwh2IAQISjBSsCnMB
bAiuU5nusrXGZkU12AUGL6Ht NoLcqS4H3itYXU6257PgAeIB7Gv
k2IjRmxWSqAQhiDxndD8qxl6n
LDjFOjNNAUCvmmWIULxHRYlLxRJj2PG7CJ1sBV2Axzvdxf+TyaIfCAd3P/8kldlb5++GTfroJkQ2
aNgGL2jI5+fn5yhouCFopBpolBNocBWz5ucMaFgFaEhXeZdFvGMQaEQRkAN2qUs86i4RSjZoPD2M
fXZyLC
AraGgYB41W8awQkAaBw6Y7mHQvWVMc20vQKJniBQFhjhRvFaRdGAF+JN23gpF a
3
jvKdAgk
QaJN1jX0A1mUBUA32X+EJwOF
0olV/H4aGRoXD38D/oDCYYgUN638fObGhB5HQLNJFNy+kKRVtJ8g
3w2TVhyNcAoahB2hbCCLSh23elqmaZrOFwOIj5ad4E1kmqSrp
ldoDCc0SNVtyn4ERxhrW8eXfSTS
Wn1IEo2eq8oX8MYzGDx9ALYEAlJjdXwmSohTpobbUOYWMG8JgcaI4SXDDQgf2YZITb9aCH1AH4QX
/gz/i
9qDwyHbfh0e2/t/r5Q+Wkc7+3zjgKQ3C3lbhr/hbzVqLUdYuaApg8EIA/iLAXX/xvuQ9Zn3
/yDMR1kD+Tv6fd5B90YwDMWoKkAS7oM8xX0BaPQ2IBT/NMWk6Y
LEzAu9H1oynJCDpPgyABnmMyCX
+Py+iHiFCZNXRiFtJxSHNwNoBCc7 8RBWDx8JJ
VB8EIUQbtrtHrsjIBHND3wHDSQRH1lDjPjN2DYF
fVFyw5mMV30PXfqDx0qdTPb/fiwsGxp5sYeXN3UzCAMg6wpslAzd3 sIbj/d81Gw
eC2jrdreRjZVj
ArNOYGpQHcnJhUYtMBnw/mTkZeEgLUbxO/I4Nw/hBTa INBmDCAOej4QkECh8FhbsLuE19yQWEhV8
DYYMQZgcGxiYQZsE6wjFQZCgIbAg7
dBf5C7idCEZQiaTWQS2r3TBxA5lrVYXrZ4m0GSWVkeGBRXO
+P22a8OzFoQrRBtoFNDQO/U6vPBhsR1bNnLDnwOrBWQzZmpVs7FO3wmqWd8HY0nXsB5oMMYG3QwS
hQHnyBCApqh/JJzO BQapIEt9B8aGa7+ffyABgL6oU1e7rHUkMGhgYz/H54hTM1+I7TazfepPJvVS
OXn0QKqv0DtwEOHaFGc2QwPVCVzl8D2ws4W
9K+8RU1gLmh3eKiwW+8LsbDYU+lkZGlAzB21tPHD7
VKys1FzmhwL4epNnCjKpBrR7cgWp6tJX2lH3DCLkgt9/UURGmnr nPRIeMNe8RJzJVwV7IX4YRtS0
UIt+eANzOQbH4EQnl0AnWTwncMCGHTgnRUCZuVtxggzsHq0W6GQwA/hocP+zM
4TdVHXtewQbsW/L
B8wrGQIPaDQnJmxw4GsudiNf3iIG+xmsFSgNaCQOIDgh2MCUCPxQBzvQS4RH4oIQD4XChBmPINeE
L0M4rFdiMlSmDEdgmFH+XJHeEWzKAglzUEh+JONBGDLw/cZmB15eE5YmU6DJaMuX8zxokFjSncxQ
aBFHQRpj/q9X6tcKNEYzT9pTuqIBOCuqxwQ4iL47uqYzlJ6wBuogfehJxyeJA+yBO699DmpDhbPf
qnYe6w5QsMMWjBMRB4LWAG7iJWyAJgAeVLf/AvBmf2De6ER0OUhIdC0IDnSBsEC0HATQtB/qAp/
B
Cs8w6yUnBFEh9O mTL8OBwaDr7zCt+f1tJjGIFoBmAR8IAs9knevl7Wl0HQR0dBB 3dV7cMSI4AreC
x9f/sYiuV9XYkct7/kJSEb8y2Yv96SPHUAwHJt56SMNtJ2hM4VYYX09QCfpvU9Fn64XgEv8gigND
PHx0Hvd0GuL8pZz7FjxcdRwSCmsPiAH/B4D/YLtUfNuLBiCTXcM8e/abymz5i72L00aKAkIq9rHu
pQAMdOI4CQ116+vVJfQGbaNNQVJ/i9FJHdxK1GgO52R10hfOO/vA4Ebryz/J6yduoUBt+bCbCOsZ
OgeL8faUMnXbdDcFAUpHf9Ucd53Z0fVEVBvD6QpJPCSlXRdtklAL
D0mAIfsJ/kSpNz5vU0L/N8eG
KYodAQcoM9F3QGhHFPdbuAvZe6Q5iVJ4TjwgcpGjNzZ+PXQ9PCsDPGM1PH8zgC2gcTyAC0EpZLJu
0RACDkZbPNd9IdqnfsYEBg0GRgeWePdECnSyDF+AJAZYY5CDpGkKoApBkgGZqKAI22mih1u kWlAY
IWowuGMbrl5QgOMFOETqEL5YBAtQob6 VfbzzpeJppIBupf6KTA28X4gK/g9wAen+919zweEEwe4E
C84XiEoBikgBGAI +W5ZlDwIGXhkCikAMBrffFeA/ikQFDEIDvRgisRXOeOsFDCzFZAOBVy5wDYJF
g+h4uYivwgQoYOwBKhUX/n3wYT2yAAtxciZQV1/orTYCXOhcOSmTIRbAmZ81i0ZCSvD/vv4DioQF
K4hENfN1u41VQXpnqguOVpeOObi4BwbOS2rXMBSQAfQWWmjUfQk5lwMYEeZ2T94NBH0NDUMECkMM
61uL1vg1+IgMTmVLnUyhiLnYc g0dqCA2hhB
dewRynuBtV58Bu/Ap RFav53QqiJ9tg3ajcwTdPQgC
+j2XujUEQnUfPAMTBKVWiYZzDOETf6WqQjlqtMFcdzf63ouct7TAjZ+00GVj5SDmm1AFu6FnjHEP
Ug/YKFAExalAZrga7Oi2eG1Mh1/TrBRW
X2+nDVUtDKoo/7dVaLtWqrGgFtWVG8CBxxGwBxqIbJAW
mo3tJkccaIgV1xhDswbJoPIWfLYtrEQQM09fJxv3gI4imllP7fxtuijleIu422jwKTVVswOSsVnT
ore9zSR XBfK4mB1Bs++9ahpUVwrJRq/7QVUUgIwiUlxfcEFMuVLcX3wFuVFj0bmEI1YFNFHmJut2
Rmj4q1dWGFANBRzg YbRpMwlIyPdSFSvk8w50gxH4wMNTSEW54aJ9nxoBrwF+CEUHD4wKwmgkd8CK
G9NA+I+JnQ//8dSyscpGmkZ9Bom1Wgk5eBveCftzoQ1u+H1E+Im9RPpC7DtzwB9eWQxBC4N8kt0K
S/VNw421T/SoxLer3V51c4uxv
wE/Rbj34AItbQWfI2EjaK0HDBMMQHe7wUn1FVAP9CKIGE4//GYn
V74KzliRLSc4nSeJI9Tq/HDr/dY5XY7EF2w3CZDoWOsYohKUwCY8IXJBwwoZMbgANJQ4R7F+clbY
ghbnCFEpDibCC9jFEDg9mTokUW6hvb+rBewHMkUhYqbH3i586j1kFJxGASdV9AjawYDSfiUTjYLI
1iQOWDJ4CVeDFDNJAgp0CgANwKVYA8PTl/8cQHPSFFSWg8j/66wiFaX3jsJbiwvV4AmZdj8wRRs5
pGJXxgcwHyJa1YCa9qDLbPxCP8A7 8FciY+pHlpFtCAhaDFEQD9+g+82OSIoGPA10DI4IdXQEPAnm
aokSEzDrQiYrESPMKv40JZoObmJGMj48OpANCtoG9WYqAgQXPQ84QA30JYk4hA3/8BB8ItrOJknO
iBA+gfmNjf1fMXK+6wFOgKQSAF3MuVAHwhVUQQD/mKG16NN+Sqk PBTFXuw4kODEyRw27e5U4OnVh
HvAjxWSmRg/cEUDsip65RtLKAUZ00k+JpnNNWBbBuWFdQh
/Lwh8KQjvXfOp1DAIoQrr213UdC+M3
Pgp18QUMKl1qo+gJCDANrusLGmJjriALHAcGNQ0c0RZUVoVDNFAPI+rGTo0K4Q020g0AjpI1Y/2F
arkNdYTzRwSLwooK6x+kKNQtPAcXODx1FPysbXwSPh+IoxX xgCIADIGBINtGPgxi4was8HQyexAk
hGko0FERLAYxaxhzFUTEr+kIgkS/QOszbqnGSlKyipQgqb7RW/n6CXUTQQc5fxKD0o0EgCb8v5fU
RELQHjB96YA5LXUZaR3Z1KP6VFq0f7aABkF6m0i9vOjULHJTOUJQFjBd3Cqgut9s5FuFVhtDXTEn
/LPm
kkOMEC
4b6j0BZifdio0Fk9AVjnlJBzEAXIAfEuVgjEBTlvT9I3JVh2q/5WKyrgfYg/vk/C2L
gshS56fWU1FAX8cPFpI
BBDB1+MN5Yc0Cb4C+eFk7xll alz3dbKsTz0iM42a/Bet23yBOMYi8aHwE
Vzf bbPPNxDR8Bz0rfi8rJnh5tpE8bFo8K8FFk/CPMT671RpgzbeBDmQ2VFM0bq1Ocwe/jTb6AJLn
O0QxMUw8ss+cPdUALM0lNCCxke5Z4bUAho+qIgsGHltePTSMaouqZePj0OsN1huaDULJaG+Z++f4
dewI7EdR6N0GQhHr7jvCAQCDByxEEQ8Bj9OboXKQzwUTKwZ+0YnIEGd+RgJJ3nVF3qAqBWgsKt8R
Dtj8apl8H3d9GNokYG vWPogTDh73WeCM6ISv/KrGlDiHUUKRJP7T
hYdP6bjkdlCD2Coj32dDwNyu
sCpoqFKgLUyaYxdc/5g1JBfQggbpn9YBsYCzM1fZHgdjSMlKYfD3QYzYhwcQEF7WOPi2yETfVx/R
JtiZrBWSSvyz5yN+vEh6ggAU3CjRZAF
77HIB3+zp0txXnzjwvAKPen3nPhyIvrlUnFtQ4HQrahkt
cgTZDtzhsrlUmKreqfhd/bFWuO0HIPSwnUtEwx6jAO/0dRi6cgCOy
sqHVRsWgCtI/+8xXtJdJ1sP
lPYUAyohcFsNDEtW7D1FkJMD6VHQDOzmAvk87Pzs/AU0bR5qX7uEQFfV7F0oTIzWnDp7CHPJyJPw
8HQk7AzE/yVL7ux0RIsbhdt1xyHUjkML3x26So Po40DdvqpCSHQ4Ai5I2wQFi3Rm+Gn+cqMf0IcP
0+slfmNzQxiy710m69do7AbQJtaARf41sQgAdFiNp2TAAMg3nC/33rl4fA8vd2KvgKVQN04t o7sk
YI9ZFV3iB56O50Az149okXRg9zfn8UGIjAX8nUA993MRADZffBgkrhdXoB7Vpo4ZrKmJbUeB WSCo
xJYTJAwgCQHvLDNYWZG7dPaC23ZCIYp5+xHYXHQ VBGzxvcUvGMaEBSJcBQVPs88BQ69cOIsIG8hg
kSsNAH9QMpjAzWmrlsFIXL9rkFa54kHiK5LZqw4xVsKXIRhWzYAbm8gPhpUBO2Nj5CafGSw3AjHA
QA +Aj45fEQAOdJreH+B3qkYxRmZYQmCHS
arBFY4XXarzNFdVifN1zhK+51I2izXWTdbNgk1GwK1T
m7NlEKXsaRrT8ZEB6/h0WgLAwnnChr5TUR2N+MqSSZru6yihU/gI5OVsWBehXdY5XYLLJlXPmlja
hF0klJVkZ7+aheYq5TC7FwZDkQi2zb2o86tOqFeqDZmQAAAvOvalV5g
je0A4nAUt9jszSEchJDan
FDyzPc0PqIglqVkgx4Z0IBgNMBgjgxB5rCUxAqgPIMggwHxEcAjBdQ8WO3c2+9coY9djeFlX9TVQ
PMDDik39ECu2akQNQ4AL+l5WW/yowC1RC9e4goFiLXIQDhciUaFV3WY6J1NmFkoNAyVkTB/D8LKg
k2jgJ2ogJ0jWBWMAXX7cor8AsNJfi8/38bhzE
T0ND0sALLjgWoR62vy3nCM8WSEFcwdogOvcXRPe
rFw4rlBzC1iEuws5aHQsJSAaZ1fyeTxzJiQnM jVwiZH8JiXcJWlw3AA3G1RzBmA1e/bYdQRn3mho
OywJ0BmbzJEeLtc2fFCB+sIKf1ImJ+Oc8IR9KQyDQ XIqCzI+ydmTHnIXEhQKD4OoGrpmKD/GR+lD
HB5C3txZigI4aNgrPHITt912SnNlQtAw60E/BwN7eCU3SGiY9/c2BDhjO7ts60FZPyWUWPJSnMBs
kDMYA zQEAnap3GhIR1dLUAMlIgw7AxiVu0XAviQlWBEwpGoZ1QUD+f0wKzgrOM0lHH2A/
P4EqM5E
YHi5TQ5fn1TCBbL/Jfh7JQBFYYYAsgAn iiIsA4g Spmma5lAAhIB8eHSapmmacGxoZGBcaZqmaVhU
UExInfuZpkRAAAgVBwP4mqZplhTs5NzUzGmapmnEvLSspKZpmqaclIyEfJqmaZp0bGRcVExpmqZp
RDgwKCCmoGGmGAAEmmV3uhATCAP4E/DoaZqmaeDc2NDIpmmapsC8uLCs2KZpmqSgl
IyEE180TWe2
lxMDbGRYmqY721ATq0A7ODAof5CmaSAYDAwb0UFCQXl22W0ARQO+vvlBAAFB8v/uKoEET177T0H1
SIxg+
UAN+////xUpKDJhMTMuJjMgLGEiIC8vLjVhIyRhMzQvYSgCBWD/fwUOEmEsLiUkb0xMS2VB
APsn5O0RBBMNQEKhQU5ASkBGzOvek2ZhUTEmLAMx3ZBv9gUXQ/c8RexsFuzBMx4MUQf2t+wNBgBP
RUBBAJuET0UUERlxq FHEI91kI8qhJ3BhnVzZYP9bJwFzSNlgk9wx/F8nohFEdvIA/v+PpeF1 J2BN
SENIBO0/dCaUQoJj
AvqyNDe3IlZpZ0y+Xuv/u//fAK04MwuAA3oTOKrhTr4ARgrsH5Aq2QfAQf/9
//+Mx+8BuMujaHvf/vvVSnZXEgYkrU/rI6ix/MwZ5////w7sPu8L2mAakZPKZ9qyludSSfAro1CO
ZjVg5f/////qQXhcz6nUC63MlgdrUq0SUE
KZRIi9RKl5tsjTviOi9P7//z9A92FvV9Qv24xMD3mc
oDQO
IV2wmiokMy8kLf //hQDYJS0ttrr+Ps5jZDJjRmRveWvr7vY5b2QitIZW
NzhvLWY7Vf/7/38i
KDUkQTnlK5YX9oapmjFhZa+ PVvyA7k49tLv9//9rh8YGUgdx6UDU
B7yZ2cEo7rYFyvAaHf+WI///
//8dyGNQ0SrSMNm8zwI452BJ9QgjZF+3AfIBgRAbH2f////P64b3qBxRbpcSVQVDwKfgmYm6kqan
jKBgl0Z2//9f/oLGTJS1rFW3vhsERKii6Lnirr2YQ8bLDWvMA///w/94u77A
tzDGYyDcTixNeaS8
Bav/5eiOnwohCv+f///6tzH9/v+HP9ppu2bgq8RxrpVEXMlFeJGVmKSP/P//2JqnuT3jXiQX7YUF
Y2i11r5rAuZi1Xjh0vP//
/+9ghgaJNONTc48ta6+kBzFxA4/6S6hp22/VQJA/////+LgUEkPwz8S
tnSze/z6k5Zr0JLHqkZNUFdESE9VRUr/////UY91nL5WR0tOVEFAQ0JCRUNARFAvxJpEREdGNm5A
JDX/////H5q3t6AILzUsNQZDAi4vSSJPJb6s/qASNSAMFMwtZc3/v/3/wK19RHYSFxYrYRhygfcZ
scz8+bx7cpqy6ofEdLf///+/SEBHdrg+GjlyD8FkQcqHEmqGEczFfHlulv4Rt//W/8oEPb4xRb5U
xVFGeoLIBC1Oz/+BuXoG////mBuavL89lMzEeXkRKdNQY2m60GzZUG5lOP9/+//LzUQdtp6ev8G4
HTW6bjVOh8VEYx3J3UR4Rpr/////Pzo2ynxha
CskKzlCvpbCgUI jJUYhrPI+ygwlTu6JEAz/////
KRlQYBOML/uYzHxMNcKF WWO3qPv+mytDEitCKf+BWl0S/7f/ub7s+pz+uClOjso8PcgcJf9BS6pQ
/9/g/xwxrqQ+uj9lyhSlMcKjPszNTHm6y9VU4P///7G2tze6cVC+BDFDJXhEPZ3MYRIQESN6Kvce
uv///9/bKRhZElEXUJ6ZQiA2WT7nTsGPYUSWXKDIHkUoef///2/4gVMtJ/E2KXQ3DEe+8p5axKl4
7MwE+UlZhVVW6f+3+K1crSsdF1tlST5OvCYpmo2waRcjv/3/f3sNRNVO3K3s4Fo6Aa1RPagHGBLy
Qu1B7FVJ/////+U9Vks+RJ/n5T8QnEEtemCYn/aHSjE3RMpH py2CGmrZX/j//1G4ZVpOzZYV93yY
cV3WQjwtXuXMl7ai TXq3/////+7luBjinUz4HenVQdfKdHmTscOwl2t5ohHHLnkglE170P///zxR
K1AYdIMvyrwEFYYEUQXCRhGYK0DBLIzs////v01MW33A
J5EBJZg/8nohxIE1VCu+vRUljCU9LBkp
TL/B//+X2S0eor6Evx8awoQ1iIKqzKpLyq3CrW3//1v7Bq03aAeP0Vl1UdPWWr4gcUqRepLIFLkM
/v+X/oZAFsq+roeoc4GpUHEWTRZJFBjCDLW+wiSO3+A3zQr2vfp+rMUEDkVhzv9v/P/MvSVJykWA
egNNNQ1yk6g/UMo0uXhF1zVEA/////+XP6ovDj2yQnRgtcSTPUxWasSs gr41sEV6NZBFN2
AEWv//
///XixhMMdJsCj9JTU5HEpf/+BfxKxhDekY92Ed
/uS71tv3///+BPVcsJo65yEXYAsK6USzlHBr0
Kq3RtUGTqH6Zjjz/v/0vMxDCw
UJOzMJP6WYA9pwsujwqygZ7DA9931j4/4krejnpEXJybtbQgQwY
AcxCtopV/////zd4FtVfTXhxP1FRLqwumsF2Tai2cHqXPEZXz33ZAvL0//+/8LM+7TyGnz3Pvk fb
MvaWPEV3M nK3GCoUaVsr/9/+/0n/VFddd7eVsgK1zFVxLSFWXDxOyl DCgEXIFcT/rf//mXysq3M0
fi1AlVpSTBhIKydvWajfScl2Al3o////wodGerI9Z+Bs+fUxmrlghW
2CsC4n9zhTfBg
Y+AX+Xw+x
xH4DtGUSyhxJF/XKcRetz9/4/xdFjL4yTUlTWcq5ysS+ParnXzp2yg//////ywW4RWIywEpaGtHs
QEUy4ECok+y6nHdO91tshknF+0T/////CUdNJy/ e6jV9SMTzqZ1/Ie/ik52FA2FOw863gh4mVhH/
////JlLLGCCMqjzYKp45IBsYeFfJvT8VquxHoL4+GAjKi4D/////oELMfVF6fzxSyj9FAY6xXz8g
eHhJyD3EnXmnDg+Dcsb/////eZ0ydL1GoK/yfktHPe+YqlESRkODqlKeWcUeSUSrahc3/v+l4R3E
tyoSqp41ZGdGocoHoCyZs3X/Rv//Hgl5Fy1PKR/WX3VxIz9hqbt2cpxyS2LR/wv//1BN9JosE834
xgFNRzRFlZkZ7CyoyokwQFQv/////zT37Fye2XE1TwNLwrsCq18fRqhJrl6BAaq5/3U Wx0gC/sb/
S40x
TmpJWK5L0VMfoOu8yDyxKUvSv/03hTSt1t1H8ux+VhdPBK/D2Qy0v8H/0lH1YPMsTr3E1eLK
e2It+
DJA//+3C84WRuW4uE2Zmj1ZT8oIT5hFwt28OVz/////TqpTbjJ8Uv+/MWxhKSVQxr0ss1hY
xRq9jY00vRyDpw//L/X/M1BSUHe4kfHIgmpjKtkfHvvwlMPHs0h58L/A/9k1Cf+VdAQyMbYwiX2R
Fhc8+cyt////v4Tea1XAeS4/WplKes9mKyV+trAFHjJL5Eqs4HHVnfT///8IQ0WigvfoyhpjJWVn
FEo9Zaex8J9xmc9LKdl7///Lv0FhvnaevvbORnKs1sKKvnhpGD9
+epw9YTr//4X/DfqFuuyx/w2Z
/1J5//aBL5301izYLLgb PVX/S/z/cGC+dbE3ILpg5DRDyp9Llz2AElztgDcy/7/B/wQY5WeZFomv
jNyRTrSxerTCqUIQKV15wHip9P
+/4KP3bP2d/OnCvwF6R0k/Qv///5dNd/mc48VlvgVCwrjhT0st
/p1VETwRH3qxPy//G/z/sZIlXj92+j9kGEvSXVTqVq67Pgo8QAcEv9H//3qvPZoC7UYphUhsHJ+d
Hl/DfLcwUIGVQP+F//9NfH4Nhs4+USnRHkCifS+9KdrEnCGrbq/CeP/W//9tNUvbzV2T7kcrrxhJ
jUVNiUlAdEW9JtGn1vr//1u3P2C6VBBzPttRvcHlRLwvB1/bbAQBee3f+Leul5Zw0YBMKW7Jk8Iv
N1cizv//L/TOKVNdN0n0SXFjutjF7HH3aVRRwIOxY1P/////XCz3ExcE3pUXc4Sp2SjCkAFAGK9m
fPscgb8VnhKHBIX/////Qhxv1oqELocnhjWJNoggiqQz+FaLM4okjR2MDI8slm3/////1iiOIpGQ
bpMydorvKNuSlZSXZpYWmRzynXeYL16bJZrAC///nQ6cjDOaNGqfXp4CAqE0oEkcljXd//+/XqVq
pH6nF06mqvvvKqlWqG6rBqp+rV6aRKz///8LJROusS/JHLD3tdssknS0b7e2N9+5uNnn9yr/0l/o
u1K6NcoFlnu/bXoEgf5HTxG/S////65uS1xEkFnBOcKDAE8yWFVANG6nLEQ 6iAUR2/+/wU9j7djs
gDTmgVlBSUkxooqB4Cckh
b
r/9rQpAeepj5aGEyQmKDQKMm63///tM4GwBy+SSrOyN5EoIiQMJtvn
ETMubb2h/7/9/zZ3N368MjsN+AypxsCIsU8JbIF
tIVcbkcapVRL//3/rXeSIfqZxGYFsLLS8NEgB
H8CFYIIiR
va/bjH/////uiufHJ0AyEeOAR6qO5gBzaDieFYDyAB
RgYY3hjxWaEX+Rv//TF9KTQ3K
XEULXrzewid
JQU/5oV45uob/v/G3KjGSymztqlk3VdoMKw5KKbtaPGN3/xJ/4x6hqvZqK/JDowd0
lH2X9FqFFtv/Bv8RSXLtjzT+KXAiXDE+BOmIrOwAzFv8//ZuTY4R4nddU0MO974UFMgvWcjlYf9/
iYVgDM Py
J54rsD 9ZM1z5/vKotyH/////7ON azAZOJll6vUePXDpJM0uVBshKBnf68Zr3P8ggXST/
/y/9UXKtBhRJSQz2YRRdZV2GTRGCca
3Q7KBkUef9////5T5IFpuBxPGxqsQuFC+Zl5gZ+mk0VuWD
4VbBw9ubf4H/L0tRtkYayrp1AiU+kJ8REYZTCwJJ/4UL/RFsrfMuwdRFNDgUbXytPaBxRrzQ//9E

EilRWL/c7GCcXnn90d9x8/Rl+0DxLX2DC4tLgBVUu1uDB4j///8LNhLLmcu6PbC3/gCCyrvKkICh
USdIgKhD4MLb////4IRN/7LrHhqAHOT0nb4YpcI/TUE0s 4YHTQOUmhJf+v9T7HchpyFTggo+Qm97
rI6CEgs 4FCr0/6sPMYT3vFzRBnq 4JGf/F/pb+B+OSUIHguzRFWA3OjHI4jRE/////5V5B0lii9Sb
qWqJCoLua+72UwbzyB/0Dqp4/uYGh063/////3qOP0cKnoC
iQh KakdkqvgOOyBdFNfPKigF0ATKg
gfQY39rq/4Mm5IkqlYQsUGE/PMoMwFr7Ff////96
SgE1eoM9CNkR0TmJvh/o+VOcNtoRVRiEesqG
tpGHcv//N/jm/+y1eMc8Z1N2UWY9yl4seeJwRyh9gCb8W3yrKgxPF4tH71IYRvLYFxT///8vlAa2
ehbnc0YJFgh6gDVQcuL0LEpKiwKDNngtvIn/v/EXHyuDH0XM8+ rqvk8eC2EKrAkGx/9/q3+64fqR
Q3m/ufhm6tf8xyp QOzl1OxA5of///61pEPVVRhgLtQis6y2xNGC4qcCk56
JeiBwH//+/VVw1Q7aU
BPW49izIyN6G/g10N JDCZ0Hj32ijK6RZIhy01UCqR5CK/7/9fzZdDDSvEWpccLcKPa2EV7aTcIeB
RQg0tTua/y/Q4q9brXtpHMwvRV+EYaj0C0L6b///zXoNupivNRx6vN9ZI5JoH0nH+jpZNK43Vn+j
ErcLH/rvhGwgWa18vhf6t/pqGSzu0J8eWV0OofR+f0UP/////zS abTvDaRJKw4VHmhJ4KKLzIXoB
ck0quTQDRiB6MeY0/8b//994X1+sw1esEBbo2
Uo
8meX327naTWeL5fSb//+/9JyV28oNVMgNoM+L
ZQ7lmb1e9jv30Jm5JVmC/v+l/5tfPZFnXJ3wHpDYFojQ5ydlImWdv5heCF/U4P/fBZE1DBb
OvUO9
6ndyiB7IvWb63+Avr
sngdht1X/krzKEAf2Uaki////8XBD2mj17UnVEhc3OdSQKxl3oCSmRV5sI8
RBg+2/9C/0as87UL8sXDKXhNEloRyT+WdtDN/////y6
FI8VGcC2Ap0MXwMMOfMz9R
/5XH6RCYywk
ypIybBQxv8WN/tGhmng0CCA1SSptuB7DWf+g1NvbHbe9iT9PRNJT9dsb/f/fprdCW1hJgx2qP+K a
FKMVkdwViRVHQv9/62zIARes24pJek5bYpYvzJ9Bif/03+r/8tAhPd4pJiEJQwg2TT8NIeQCgv//
/3cucXoMUZ4pyvGh/2cGSfpUPalg TV0Z3ELTFPUc/8b/W9LA6GH7jjmIiHL3NUdCF8FBJq1r6f8X
/ji6vhw7bVRI011dGDkXFyceVR3DGnnf+v9/Q7kWB3qHnx85aoLXRT9EM7U1Bfw+fgyW/y/0/2RI
F9wX3ZUS9pSu6upR3Dy9N1tUVBkXRv////+TNlRwzdbhDe+q6hImGDH9I8y2VYg ARRd3/DVIERBu
VdX/G/xEWWyDWaep2zGwJSfNJoXRFuE3KPC/v+3RvPxRzRfpg8aty0C/8P//xZ2fEYsAqYTJQDOr
RDJaeSmGL0tGWmqLyRT/t///4hRLWQ7MjyKvcYcTgVjQZR+8BM0xTeYLJy2uiF/g//+fV1IONItP
Qqkk3TsH8BgplMwRFGNK8fT+L/T/QRPs9GNN+YQ48qt223KBeUI1YAHBfUK//f+3Q7h
XQoLLCb4x
6N477U33RoeKIUCj6Fdf4Nv/HE2p0AsSEyL3FI5E4r1hOKyAva7f6C/0gFU/C1m5CvS+U8N7RKl9
ry/1/1v/cz1Lvpz+eqOAcapby19bUsH/v9T/oOket5jYWohaNku2vrhhWABCi3XJTwfJ//+/xKFi
HYVOvrtNNPi9F9DZsS0lGY
LyEcL+Bf//L/WaVUFCekBiBC
aGAVLNHj866oyuR0m/nfv1/wv/2U03
FXNRySxMqin8FurkQUtNYJ97S////y+32aoSsuTj1w+sGsRNBNhTGDwFqYz8xbhP2aRH/1Lf+kQ5
NlOa+fStZYhBtdJC5E5g1db/rf
53bbCJ2TlDwFSqT9HKpahvoU73/gsX+J lLyz3x1Ca+Z01Mycw+
urf9//+lUkM1aAo1VkNKtpdKzHK2QoeqaWS5Pir/L/RLiJ5yn6pcQ7aSYp68g/qPvGK/wv//20qe
SlZOn/Ritkqfz575EMsq18zZr0J8//+t/4CcL/ 6xGGoMaStFkq/KSZKhRa1CnMHo+oF/g///SrHz
QifDcx9A423E6G5MentiwNcZAWK1/f///
09HZJ8j6ElZmQrKlxoZooOaV7x5xgs0tx+Igzs0mf//
/y 90dgFReS1sbvDvFvtRyoBCbZjkLMBuQ36Ao0Kt4////8hTMg6emaMDoSsBBh76XEAPVfsRoeRq
6J4z DJL//9+qU1VkVxBxs7TLVVDJVUkAPMkHLtMzs/+NfuvM
CLyCa4S3WhdDgjJhx0kiA1r+/1/q
rafoQIBbwlK54fGQxPp4HDCi3p43ntf8v9QNng9qv1ULzDUQQpbLRdyR+L/FG5 1LyUWOijO0Rhye
CYB1l////99BTlH4A57EbPf3eSdHzuteUfwwaqbbvRj6+VL5wf+/1P/8jJEuCTNCKzkY1RA0AvGX
Rs65EUpSbiB86///GWPBahXOVUfI9QEvU80qFlQHGhKVekSj+tb/b/FcABLor0RJRna0ovg2oHSG
4l
Yb /2+UK6fgQVwogbzBtha/ArlE/i/9/4LfZ04n4ENagMHEj82JPta5GNmhcoCCHX//9v+tMsCg
xOw03qvAuERLVyREV7ksPE3p/////wNWRr/oUWRCzp+fR7G+fEVR7TURBzoZND2CEBf/4SMX/43e
+rc0SksYGesds57tWxEJ9h2ee9/iF/hEIxmqTgpfEL55ZumRtplaN/pb/4FCHxj5Ce5KT7V8x9Er
fZvGLvr///+SlsxAXFFQEW5FEXW2z68sWZIfRU7E4+pqcRq6D/8X/jc5emBTzqzGPFHfpFcRbVc0
OMpRFsH0t/jt1hxrw3QRBE7RWJ4hJCffp/9f4m8sJ2GnSzYZGRvAW+LtEVpAWf2H7Vv8//9QiRRM
ZZ848VxUN3IW+StpyzwoGr8bg1/4BRb6jXmJW3pjQyupG4AGp////5dVYWhfkCmM5VC0GXuQgw7/
I9RRYh+rG8RJMpD9X/r/lkCQq40sMvURYKsEvXa6rpyvTv6OYUVQ/63+S2VwaoDkfQYnwFGe7OI3
PaUJ2Pv/X/hqB8zDBvI
x+p6z+0cSCWt9R0UBnkKKyT6N/v9/LLxJc4gntpiaC/UaK2y0k4McA07e
dP9f4P9IO4Cq/9ePR1yE1WwqNfcN1nqFYcqy/CX/////29jl6ZeQd4k5UZKpSreasJzuzNRX5XFc
Y08UqUvK3EH//8L/bGBc65FNbvEEBg5dqf9PASc0uuMKqzOxVC3/X1jos7cE6v0YNXbMzATUwveK
6kSmf4m/9 ffIIgnGRZsTpv8xEEGAqykMOf////80qNEna6GdSuskprHuTWHVfm8OXaz3tNSkulFh
EB3L
lP//b/+4Wgo3wA6nNBMFqEVxVt
TumrLRDa48sXO2PK2txP9f4oaHwuEa4FCavLfHSPqgBgRo
Rv//37oFrZ6oqfn08CYeSEOtfXCqfJG3J+esrapf4v+lMbFCcw4puF+q7jjZzY01HWouUl/g/zc8
c4GkyQSlwzH/1Vo6nL/L/7/A/1A9bJedl1l
NIZxHXqtX7fggRBlhSRylof///1gvbnmqZzwxGGM0
pO4V
N1jgVDApjUFBa2Ev/7/Uf0i/2qdpzVFApSAlBygtJFhBvx8SJDX///9GRi4 oLvK37fxOFjMo
RlsCM2RKLqQe9wBmf6m/1AYVuCoCLjRMLc+ct4D3M1cE8P//L1YkLDE
RaClMCfB+mi9wMQd3JEjS
L/Uv7S4iY7+nn5rfS
SQyMlVgl7j9/zIkCSAvJQ5/+oQ+RSQvIiD+Lr8JgP9WQK0lNC05DyAslv+/
wH8lJTO
Cj0OnBIkA6i2XJ5wVKUclPaM/1v///xuIvyyyMTgNLl0NKCMzIDM4c8RunCHYALggTi70
//8zEkkvTMH
2JhMOIyswVQQ5w5FfvAUk60v8BRoueShXC9hcAhcgLcTf4P9/Sob3JG0ATg4xWwok
OE/mmB2uTnXnNfi3f4lRSbE2MjEzMSe6PW2K83SxT//ud9/QUVJ18wt4RVZIQIMJU0xDMkm3v0j/
GfXSODguDUBDIk+z5RhlQ1H/L/0Gx0EngI+PzVpFckYZdhq3EU17pf7//2lRRhHPZFpHQi1uGFZh
7VdBJf1f8U5KHbxwq//FOQQnY9G/NyCqRWJ6IW8l/f8vLQMg9qUqTQoBV4FBwSC6Rc1xQo/MiQN5
RhRhviGoY/+3bRFt
zAWBvr4Wwoy+qlH
RAMt74/+NRzJGBkCaNEbKX8KvvU8zrPlBK90O2BFQgQwy
rioOpS7BBzKlcIhz
M0zhHdi3ukk9wo41NciEL4jCQvaEDDRhABxMC/y3f8KAQ8C8QbKVwpBAzFVu
wrz5TkrxRu7LQwOUpLaoIov+0v8N9EPCg0XIRsKGRcIINrBAjqgNl9i67xYfyLb4NanLKW3NQDbB
wm/1tsF+QFbKRsseRVSpNvj9vw6BUceFaLnBqqlAsTtEyGmYt98a5f9MI0iB
NQTKJ8zFdd92hXEY
67IRH0m+1yUL1Mv//9ZOSR2dyLg4Rk72RgYRBvgWCbPvFCk3278zN0bIQsKCRaqZEC0gqAJEBeaq
+b4AuZBbowMTJTHYIWmGpDXnPddcYJvwxTFX/Ysfgww2SJupB7dJqvQjAHVBCgQTD5yPUf8X9gUN
DUEABRcAEQgDQRQSuckHaxoKFhJzHjFtg9VqTe5OAA0GXK8taPCHIoGsYCy21Q9IKBAMQedqtbbA
As6/Ow2oSvgvMCgvNScA8xRFWEVEgYDAGo0WCAjkAQAwCgAkUQW/aSYgqBwBRmluZ
ENEAaDybG9z
ZRtEzN4V1FNpemUX73/7TEwRQQ5NYXBWaWV3T2YPbm9hbw5Vbm0QLgNycyJud8MvS0VudhBvbnar
io5dViJhYhg5iLgdRAx2ZdrukYqYDn1UaW1GKuKstVcaC1FDotu697ELe3BeZy1Mw25fIH5MaWJy
TnlBIfZMULRQYyhLxkQ5tv1iYWxBbAZjWExhtz3sVNMqTXUDeCgbm7VbbBdyYw9+sHQQB/vnWlYd
RkNvcHnFRGXahzdr BoMXJUhh5wsg3cKdRVNj2XY7+WxlblTfcFAvaA1h
CwrDVytYRB2zt0VE8W/K
kbZQxMlweU2RbFt2 Z4IiTRNFeGlCQfFi3WhxZB/x
vVnAJv8vmY33hg27BWVwoTZCN+LCw7Azblqc
ZUl7EXGiy/sXbCD8XnIYVG+TFYaZorhMqQ68JXsTYhENCGNrQ4VvT0RyAeNkZUNop9xdRGw0TW9C
eXQiEhQnIpyeua+1LQpjmDYqUqCyvSfhVEdQb2koGUh
7wWbtcEYmXL0TGYRDmDDoOm5FTLisMGkJ
aZwWpCImBDpNGDPXOEN1GH0ZOiQ5YW9rpURlLJWEIMWVaLXHHuObwGcbS2V5DE9w69yjazELRWoO
gFZbvQAadnVlD4vM3KWEESl1bTAMT7PNJrc/ZML4baCiYW6Hc2UwijcXa4xyEPYHaXNkvfZcCXoZ
8s4QFKJ4rltQCCI5N6ErMy phKiECSg9ms1TNIAGhVVwPFrDfTkJ1ZmZBDwtMb3f2GbYjd3ZJcpQj
dwqFm3Fa9MwMTYLCAKhtWbZN17fYYkD/BAITC2VZlmU0FxIQA6tlWZYPCRRzOb//hLw8UEVMAQPg
AA8BCwEHrnvSbBNyKoAyBBADgmxnsZA1CwIzBJlb0s0HDNAeNHvZG9gQBwYAwHkIQIBbZHgCGAVG
uMJ2K2R4AR4uL9iToJikcJDrNn+7sAQjIAtgLmRhdGGYI+5CusH7Iid2QL3NYBuFLuUJAMPABny/
KXs0J0AbsHsNlAAASkE8CQAAAP8AAAAAAGC+AJBQAI2+AID//1eDzf/rEJCQkJCQkIoGRogHRwHb
dQeLHoPu/BHb
cu24AQAAAAHbdQeLHoPu/BHbEcAB23PvdQmLHoPu/BHbc+QxyYPoA3INweAIigZG
g/D/dHSJxQHbdQeLHoPu/BHb
EckB23UHix6D7vwR2xHJdSBBAdt1B4seg+78EdsRyQHbc+91CYse
g+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYPigJCiAdHSXX36WP///+QiwKDwgSJB4PHBIPpBHfx
Ac/pTP///16J97kBAQAAigdHLOg8AXf3gD8BdfKLB4pfBGbB6AjBwBCGxCn
4gOvoAfCJB4PHBYnY
4tmNvgDAA
ACLBwnAdEWLXwSNhDAU5QAAAfNQg8cI/5aM5QAAlYoHRwjAdNyJ+XkHD7cHR1BH
uVdI
8q5V/5aQ5QAACcB0B4kDg8ME69j/lpTlAABh6SNE//8AAAAAA
AAAAAAA AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAA
AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAgADAAAAIAAAgA4AAACQAACAAAAAAAAAAAAAAAAAAAAC AAEAAABAAACAAgAAAGgA
AIAAAAAAAAAAAAAAAAAAAAEACQQAAFgAAADY8AAA6AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB
AAkEAACAAAAAxPMAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADQAACAqAAAgAAAAAAAAAAA
AAAAAAAAAQAJBAAAwAAAAPD0AAAiAAAAA AAAAAAAAAABADAA4MAAACgAAAAgAAAAQAAAAAEABAAA
AAAAgAIAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAAICA
gAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD ///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIiIiIiIiI
iIiIiIiIgAAAj///
/////////////4AAAI f///////////////eAAACPf/////////////9/gAAAj/f////////////3
/4
AAAI//f///////////f/+AAACP//f/////////9///gAAAj///f////////3///4AAAI////f/
//////f///+AAACP//93d3d3d3d3f///gAAAj//3f39/f39/f3f//4AAAI//d/f39/f39/f3f/+A
AACP939/f39/f39/f3f/gAAAh3f39/
f39/f39/f3d4AAAI9/f39/f39/f39/f3+AAACP////////
////////AAAACP//////////////8AAAAACP//// /////////wAAAAAACP
////////////AAAAAA
AACP//////////8AAAAAAAAACP/////////wAAAAAAAAAACP////////AAAAAAAAAAAACP//////
8AAAAAAAAAAAAACP/////wAAAAAAAAAAAAAACIiIiIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD////////////////AAAADwAAAA8AAAAPAAAAD
wAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAB+AAAA/w
A
AAf+AAAP/wAAH/+AAD//wAB//+AA///wAf//+AP/////////////////8jDAAAoAAAAEAAAACAA
AAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAA
AMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAACP//////8AAIj/////+AAAj4////+PAACP+P//+P8AAI+PiIiPjwAAiPf39/f4AAC
Pf39/
f38AAAj39/f38AAAAI9/f38AAAAACPf38AAAAAAAiIiAA AAAAAAAAAAA
AAAAAAAAAAAA//8AAP//
AADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAOADAADwBwAA+A8AAPwfAAD//wAA//8A
APDEAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAAAAC89QAA
jPUAAAAAAAAAAAAAAAAAAMn1AACc9QAAAAAAAAAAAAAAAAAA1vUAAKT1AAAAAAAAAAAAAAAAAADh
9QAArPUA AAAAAAA
AAAA AAAAAAOz1AAC09QAAAAAAAAAAAAAAAAAAA
AAAAAAAAAD29QAABPYAABT2
AAAAAAAAIvYAAAAAAAAw9gAAAAAAADj2AAAAAAAAOQAAgAAAAABLRVJORUwzMi5ETEwAQURWQVBJ
MzIuZGxsA E1TVkNSVC5kbGwAVVNFUjMyLmRsbABXUzJfMzIuZGxsAABMb2FkTGlicmFyeUEAAEdl
dFByb2NBZGRyZXNzA
AB
FeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAbWV
tc2V0AAB3c3ByaW50
ZkEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1XVT0f6q9Egq
AXoO1Sk0LdUgrH/VdwQNKg8OASpy7ouN2FJNpgf11EyDXzsNJ62zpgfz+augB6d94aiOTINUc12v
xdSy5WcqsmifCbITcO+yQp40nBDTCrJgLzxvquy9cUSd1p6M8Bqenv/z2vkQvd/7Lz6BMMi0SQPS
I1qbMV5rZlPZhBiYRoQnRnfQyf5VhFqtXYTCbn2EDwlaQLnVRdg651o33theN/zpmTeIebZj4wy
A
N14bnSgJDYNkz78oGc1VBqOlP5xnE6vf9gAfjfb467r2jjnB9riFqfbjr8WxyQwlXrO4lF4Tbs9e
BrIxXiR6Q0G+59ZB+n2jH7BGY/iu9lDTcUXvCJcMTgi1NwPTYwhAF2ZC+wi1uzoXx2wE44IIKwzB
GusM62PtDEXxmAxvVJgTmRggE7ghF55E4bCq+8GQRTPzF0W9dMVaZN
cpRVf+UIEkaX1awDrd03Wa
ShU68xpoiN3a5dcNT/pnUd/lTueUrg8IH+WlhxPlR0pzy+BWygq7U4FlKhsDJCZz7XDZbYkkCJSr
8zZvy zvbrIXXT/+jJ3yMLRF8NHM4c1HHofGxVCd11Qn8kGL0J3wEP7nSrIBJrU6/Sa8UDxQkIvRW
FeBoXhFtEkmRl5lWuEwkd7jqOofXm jCYWmUGmHDZSJhiIeeHfB/QkErYfJgiBMAqXJ7B2svwdtpv
ZYZe9qP3hUJvLNptdmPab2XS2vR6ozM7bX3G+2rlwwCWqRVDLZXcooer3AfDJcPOvJvDuI5poT7b
BU741YQewyHtUUhvflEHJ99O
e+S bTn/OAE74zpYi5JvU0v/PdtJgtSZfVnUlzQKlOM0s9ZXNpxX
q
jTIt4QxPWNz8r5Hy44Ft6OMFjf38ICj549W+Ifx2qndfPdERcILQqYC5KR
GAJXn
knxhWvZ/mKtyf
ZOFggLM5zp8DIDtUHthlpGhpziojARu7xz68pK1X1rtWbicprOn+u7rmZ/TR+VQEwqdnG520rBsU
AbmBBlQYG33OZxv8A4YTh3todjseVpl4YDtdlFyMmeFLxJnWQnWZ01VrmbqautmbgCiozOdIBxpL
BmhKBEHPMaAjBrXDV0dW9a
1YMgFGRwrDlSwWXkUDEmSwCu7uQdwNDPWSZKfP3C2VHsPMkyLDUY/6
NSdxxB746EnaUqq0xRaTvdpODAHa/of
V2v0QqcUUELg57io0ydfYx8mYB8rWShTYHz0GM9aGfALJ
1AMU1qngv6uq5TJbkM0GW+mxZ1uTH+Zb11twgHVm y9z y8K9EQq6gns3ZPXFWfyVcbfqlcSnnhHEC
bcRu/lsgcQXor3GLbJYvXFh6lJ7HIUtz157AtBMHgKZO2gWTKofZ4
tc8wB1Lmum8vHYGe+aX1Zde
Mgbw6lUZjVYEwzb9/RnY+B8GX4OjKT88Xhtmr+DOnuIfxgPCgujYCSPZdPVhAuC8XcZK6F8aFhLW
9
VV8Q+piAWDs14eh6i7mO/XZpKT1ly/YJfD+Ii7OP7f
BYgHMwSgJfMGGgtoupUTiLlToFi5ZhOsu
dkCKiOR72P0z1pR33vxwd32zkHc9p3CIH0A4iHs6r4gfVz49I4rlG1vfD80acCaWngeOPYoMX8IG
aO09FyaWPU
sLIlBLAQIUAAoAAAAAABx83DQ/EnZDwHAAAMBwAAAPAAAAAAAAAAAAIAAAAAAAAABp
bnN0cnVjdGlvbi5jb21QSwUGAAAAAAEAAQA9AAAA7XAAAAAA

------=_NextPart_000_0012_94DF94B0.895253EE--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RJoAud004825; Tue, 27 Jun 2006 12:50:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5RJoAg7004823; Tue, 27 Jun 2006 12:50:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RJo9P2004782 for <[e-mail]>; Tue, 27 Jun 2006 12:50:10 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo11u030533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jun 2006 19:50:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZR-0005FU-Lz; Tue, 27 Jun 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-04.txt 
Message-Id: <[e-mail]>
Date: Tue, 27 Jun 2006 15:50:01 -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 Certificate and Certificate Revocation List (CRL) Profile
	Author(s)	: D. Cooper, et al.
	Filename	: draft-ietf-pkix-rfc3280bis-04.txt
	Pages		: 141
	Date		: 2006-6-27
	
This memo profiles the X.509 v3 certificate and X.509 v2 certificate
   revocation list (CRL) for use in the Internet.  An overview of this
   approach and model are provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.  A set of required
   certificate extensions is specified.  The X.509 v2 CRL format is
   described in detail along with standard and Internet-specific
   extensions.  An algorithm for X.509 certification path validation is
   described.  An ASN.1 module and examples are provided in the
   appendices.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-rfc3280bis-04.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-rfc3280bis-04.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-rfc3280bis-04.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RJSOZU097004; Tue, 27 Jun 2006 12:28:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5RJSO22097001; Tue, 27 Jun 2006 12:28:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5RJSML3096986 for <[e-mail]>; Tue, 27 Jun 2006 12:28:22 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 18744 invoked by uid 0); 27 Jun 2006 19:28:15 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.242) by woodstock.binhost.com with SMTP; 27 Jun 2006 19:28:15 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Tue, 27 Jun 2006 15:28:15 -0400
To: "Manger, James H" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples
In-Reply-To: <[e-mail] .corp.microsoft.com>
References: <[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>

James:

>8. Appendix A.  Are the modules names supposed to end with "..SAN88" and
>"..SAN93", or is it supposed to be "..ASN88" and "..ASN93"?

I was thinking "Subject Alt Name" when I used "SAN" in the name.

Russ 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5RJSOWS097003; Tue, 27 Jun 2006 12:28:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5RJSOoq097002; Tue, 27 Jun 2006 12:28:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5RJSMlQ096985 for <[e-mail]>; Tue, 27 Jun 2006 12:28:22 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 18734 invoked by uid 0); 27 Jun 2006 19:28:13 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.241.252.242) by woodstock.binhost.com with SMTP; 27 Jun 2006 19:28:13 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Tue, 27 Jun 2006 15:25:39 -0400
To: "Stefan Santesson" <[e-mail]>, "Manger, James H" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples
In-Reply-To: <[e-mail] .corp.microsoft.com>
References: <[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>

Stefan:

>5. Why bother with the (SIZE (1..MAX)) restriction?  Delete it.
>
><Stefan> It seems to be the custom to use it. I don't feel enough of an
>ASN.1 expert to have the correct answer. Someone else may have an
>opinon. I'll be happy to remove it as long as it works.

This is used to indicate that a string, set, or sequence cannot have 
zero elements.

Russ



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QMo9Mj014645; Mon, 26 Jun 2006 15:50:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5QMo9uI014644; Mon, 26 Jun 2006 15:50:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QMo8ZV014615 for <[e-mail]>; Mon, 26 Jun 2006 15:50:08 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5QMo1UA011331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jun 2006 22:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fuzu5-0007zX-Oy; Mon, 26 Jun 2006 18:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-27.txt 
Message-Id: <[e-mail]>
Date: Mon, 26 Jun 2006 18:50:01 -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		: Server-based Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-27.txt
	Pages		: 84
	Date		: 2006-6-26
	
SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server.  The path construction or
   validation (e.g. making sure that none of the certificates in the
   path are revoked) is performed according to a validation policy,
   which contains one or more trust anchors.  It allows simplification
   of client implementations and use of a set of predefined validation
   policies.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-scvp-27.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-scvp-27.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-scvp-27.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QKL4Mq064595; Mon, 26 Jun 2006 13:21:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5QKL417064594; Mon, 26 Jun 2006 13:21:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QKL2nY064578 for <[e-mail]>; Mon, 26 Jun 2006 13:21:03 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5QKKqM5014974; Mon, 26 Jun 2006 16:20:53 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5QKK2K1024833; Mon, 26 Jun 2006 16:20:07 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 26 Jun 2006 16:20:50 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt
References: <02e701c69544$d53fc9c0$0301a8c0@Wylie>
In-Reply-To: <02e701c69544$d53fc9c0$0301a8c0@Wylie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [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>

Turner, Sean P. wrote:

>Comments as follows (r=replace):
>
>1. Abstract: To the sentence beginning with "The X.509 v3 CRL format is
>described in detail," add "an Internet specific extension is defined,".  AIA
>is an internet specific extension.
>  
>
Modified abstract to note that both standard and Internet-specific CRL 
extensions are described.

>2. Sec 1 para 7 last sentence: replace a conforming certificate/conforming
>certificates.  There are three cert examples in Appendix C.
>  
>
Done.

>3. Sec 1 last *, Sec 8, and Sec 10: r RFC 2510/RFC 4210
>  
>
Done.

>4. Sec 4 1st para last sentence: remove required to support a PKI.  All of
>the internet defined extensions are optional so they can't be required to
>support a PKI for the internet community.
>  
>
The full sentence is "This section also defines private extensions 
required to support a PKI for the Internet community."  These extensions 
(authorityInfoAccess an subjectInfoAccess) are needed even though it is 
not necessary to include them in all certificates. 

>5. Sec 4.1.2.4 last para penultimate and last sentence: r section
>7.1/section 7.1 and 7.3.  7.3 needs to be added as issuer names can be
>expressed using the domainComponent attribute.
>  
>
Section 7.1 has been modified to note that domainComponent attributes in 
DNs MUST be compared as specified in section 7.3.

>6. Sec 4.2.1.2: Can we suggest using something other than SHA-1 for key id
>generation? How about striking SHA-1 from the methods and adding the new
>sentence to both: The hash algorithm employed can be the same algorithm
>paired with the signature algorithm (e.g., SHA-1, SHA-256, SHA-384).
>  
>
Section 4.2.1.2 simply states that the two methods described are two 
common methods for generating key identifiers.  The text explicitly does 
not restrict CAs to using these methods.

It is also not clear why one would want to use SHA-256, SHA-384, etc. 
instead of SHA-1.  There are no security issues associated with key 
identifiers, so it would seem that using a hash algorithm with a longer 
output would just make the certificates larger.

>7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that since
>the SAN is bound to the public key that the CA MUST verify the each part of
>the SAN. I think a similar statement ought to be added to the subject
>section (4.1.2.6) to indicate that "All parts of the subject name MUST be
>verified by the CA as it is bound to the public key".
>  
>
It is my understanding the the statement in 4.2.1.6 was added because 
there were cases in which CAs were verifying the name they included in 
the subject field but not names included in the subjectAltName 
extension.  Are you aware of a similar problem with the subject field?

>8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name
>constraints on ediPartyName or registeredID but the 14th para (the one
>before the ASN.1) indicates that ediPartyName and registeredId are not
>defined in this spec but MAY be defined in another spec. Sounds to me like
>it would be hard to convince a customer that you could write a name
>constraints that can ever be 3280bis compliant since whatever you wrote MUST
>NOT be imposed/implemented. It's not clear that the name constraints
>shouldn't be imposed because they're not defined in the spec or whether they
>should never ever be imposed.
>  
>
3280bis states:

      The syntax and semantics for name constraints for otherName,
      ediPartyName, and registeredID are not defined by this specification,
      however syntax and semantics for name constraints for other name
      forms may be specified in other documents.

A CA conforming to 3280bis MUST NOT impose name constraints on the 
x400Address, ediPartyName, or registeredID name forms.  Period.  
However, just as [SRVSAN] specifies the syntax and semantics for name 
constraints on the SRVName name form, other documents could specify the 
syntax and semantics for name constraints on other name forms.  Given 
that 3280bis forbids conforming CAs from imposing name constraints on 
the x400Address, ediPartyName, or registeredID name forms, it would seem 
to be inappropriate for another PKIX (or even IETF) document to specify 
syntax and semantics for name constraints on ediPartyName or 
registeredID name forms, but 3280bis is just one profile of X.509.  A 
different profile of X.509 may permit the specification of name 
constraints on these name forms and may specify the syntax and semantics 
for imposing constraints on those name forms.  While 3280bis states that 
conforming CAs MUST NOT impose name constraints on these name forms, 
conforming relying parties are permitted to implement the ability to 
process name constraints on these name forms since conforming relying 
parties are not restricted to only accepting certificates that are 
issued in conformance with 3280bis.

>9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name
>constraints on x400Address name forms but the last sentence in the 10th para
>last says X400Address MUST be applied to x.400 addresses. See #8.
>  
>
While a conforming CA MUST not impose name constraints on the 
x400Address name form, a conforming relying party MAY implement the 
ability to process  such constraints.  As with any other name form, if a 
certificate includes name constraint on the x400Address name form and a 
subsequent certificate in the certification path includes a 
subjectAltName extension with an x400Address name, the relying party 
MUST either process the constraint or reject the certification path.

>10. Sec 4.2.2.1 4th to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP
>[RFC 2255] URI. Makes it consistent with AIA in CRL section.
>
>11. Sec 4.2.2.2 3rd to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP
>[RFC 2255] URI.  Makes it consistent with AIA sections.
>  
>
Done.  Although 2255 was replaced with 4516.

>12. Sec 5 3rd to last para: r This profile does not define any private
>Internet CRL extensions or CRL entry extensions/This profiles defines one
>CRL extension and no CRL entry extensions.  AIA is defined in this spec.
>  
>
 The sentence was replaced with the following:

      This profile defines one private Internet CRL extension but does 
not define
      any private CRL entry extensions.

>13. Sec 5.2.5 8th para (one before the ASN.1): The sentence about the
>onlyContainsAttributeCerts seems to hang. Recommend adding "In either case"
>to the beginning of the sentence to address the case when either
>onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. Additionally,
>recommend adding the following for completeness as a new last paragraph: "If
>the scope of the CRL only includes attribute certificates then the
>onlyContainsAttributeCerts MUST be set to TRUE and both
>onlyContainsUserCerts and onlyContainsCACerts MUST be set to FALSE."
>  
>
This sentence was really meant to say that onlyContainsAttributeCerts 
MUST be set to FALSE in all cases, not just when either 
onlyContainsUserCerts or onlyContainsCACerts is set to TRUE.  In order 
to make this more clear, the sentence about onlyContainsAttributeCerts 
has been moved to the end of the paragraph and now reads:

      Conforming CRLs issuers MUST set the onlyContainsAttributeCerts 
boolean
      to FALSE.

>14. Sec 5.2.7: Remove ASN.1.  It's already referenced in the 1st para,
>duplication leads to errors, and the other sections that reused ASN.1 from
>certificate sections did not duplicate the ASN.1 (see AKI/IAN).
>  
>
Done.

>15. Sec 5.3.1: Can we add an ASN.1 comment to say the enumerated value #7 is
>never used?
>  
>
Done.

>16. Sec 4.2.1.6 1st para: r These identities may be included in addition to
>or in the place of the identity/These identities may be included in addition
>to or in the place of, in the case of non-CAs, the identity.  The paragraph
>mixes SAN and IAN, but assumed the 2nd sentence addressed SAN.
>  
>
Section 4.1.2.6 already very clearly states under what circumstances a 
non-empty DN is required.  I don't think that information needs to be 
repeated here.

>17. Sec 4.2.1.6: Add the following to clarify that there is no dependency in
>this spec between SAN and IAN: This specification places no requirement on
>CAs, whose certificate includes Issuer Alterative name, to include Subject
>Alternative names in certificates issued by the CA.
>  
>
While this statement is certainly true, I don't understand the need to 
include it in section 4.2.1.6.  Is there any reason that readers of 
3280bis would believe that any certificate that includes an 
issuerAltName extension would also need to include a subjectAltName 
extension?

>18. Sec 4.2.1.7: Add the following three sentences to be explicit about the
>checks not made: Issuer Alternative names are not constrained by name
>constraints. If a CA certificate has a Subject Alternative name, the
>specification does not require CAs to populate the Issuer Alternative name
>in certificates issued by the CA. Further, the chain of Issuer Alternative
>and Subject Alternative names, as is done with issuer and subject names, is
>not checked during the certificate path validation algorithm in section 6.
>  
>
The following was added to section 4.2.1.7:

      Issuer alternative names are not processed as part of the 
certification path
      validation algorithm in section 6. (That is, issuer alternative 
names are not
      used in name chaining and name constraints are not enforced.)

>19. Sec 5.2.2: Add the following: Issuer Alternative names are not
>constrained by name constraints. If a CA certificate has a Subject
>Alternative name, this specification does not require CAs to populate the
>Issuer Alternative name in CRLs issued by the CA.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QJLwXj044656; Mon, 26 Jun 2006 12:21:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5QJLwXK044649; Mon, 26 Jun 2006 12:21:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QJLveT044642 for <[e-mail]>; Mon, 26 Jun 2006 12:21:57 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5QJLpEQ012258 for <[e-mail]>; Mon, 26 Jun 2006 15:21:52 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5QJL4VP000441 for <[e-mail]>; Mon, 26 Jun 2006 15:21:05 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 26 Jun 2006 15:21:52 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: draft-ietf-pkix-rfc3280bis-04.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [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>

All,

On Friday, I submitted draft 4 of 3280bis for posting.  A diff file 
highlighting the changes between drafts 3 and 4 is available at 
http://csrc.nist.gov/pki/documents/PKIX/draft3280bis-03todraft3280bis-04_diff.html.

Draft 4 includes the following changes:

1. References to RFCs were updated as follows:
           RFC 2247 replaced with RFC 4519
           RFC 2253  replaced with RFC 4514
           RFC 2252 replaced with RFC 4512
           RFC 2255 replaced with RFC 4516
           RFC 2510 replaced with RFC 4210
           RFC 2587 replaced with RFC 4523
           draft-ietf-ldapbis-strprep-07.txt replaced with RFC  4518

2. All references to RFC 3279 now mention RFC 4055 and RFC 4491 as well. 
(All three RFCs are listed as informative references.)

3. Section 4.2.1.6 (subjectAltName):  Reference to section 7.5 clarified 
to note that the section addresses email addresses that contain 
internationalized domain names rather than internationalized email 
addresses.

4. Section 4.2.1.7 (issuerAltName): Text added to clarify that the 
issuerAltName extension is not processed during certification path 
validation (i.e., it is not used in name chaining and name constraints 
are not enforced).

5. Section 4.2.1.10 (nameConstraints):  Clarified that for DNS names, 
"host.example.com" is a match for the constraint "host.example.com".  
Also clarified that constraints of on the directoryName name form are 
not applied to the subject field if the subject contains an empty DN.

6. Section 7 (Processing Rules for Internationalized Names):  made 
changes based on comments from Kurt Zeilenga.

7. Numerous minor typographic and syntactic errors were corrected.

Dave



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QIp1TV035088; Mon, 26 Jun 2006 11:51:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5QIp1Oe035087; Mon, 26 Jun 2006 11:51:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QIoxNC035063 for <[e-mail]>; Mon, 26 Jun 2006 11:51:00 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5QIop7k026704 for <[e-mail]>; Mon, 26 Jun 2006 14:50:51 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5QIoLq2017145 for <[e-mail]>; Mon, 26 Jun 2006 14:50:21 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 26 Jun 2006 14:51:08 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: draft-ietf-pkix-scvp-27.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [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>

All,

On Friday, I submitted draft 27 of SCVP for posting.  It contains the 
updated references mentioned below, but no other changes.  A diff file 
comparing drafts 26 and 27 is available at 
http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-26_to_27.html.

Dave

David A. Cooper wrote:

> Seth Hitchings wrote:
>
>> Should the CMS reference in section 11.1 be updated to RFC 3852? 
>>
> Seth,
>
> Yes.  I believe that the [CMS] reference should be updated from 3369 
> to 3852.  Also, the [UTF8] reference should be updated from 2279 to 
> 3629 and the [IKE] reference should be updated from 2409 to 4306.
>
> Updating the [UTF8] and [IKE] should only affect the References section.
>
> Updating the [CMS] reference will also require changing the ASN.1 in 
> section 8 so that ContentInfo is imported from the 
> CryptographicMessageSyntax2004 module rather than the 
> CryptographicMessageSyntax, but I don't think that should cause any 
> problems.
>
> Dave




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OC9xq4027774; Sat, 24 Jun 2006 05:09:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5OC9xds027773; Sat, 24 Jun 2006 05:09:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OC9uGD027749 for <[e-mail]>; Sat, 24 Jun 2006 05:09:57 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jun 2006 13:09:56 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: last call for 3280bis - escape clause
Date: Sat, 24 Jun 2006 13:09:53 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: last call for 3280bis - escape clause
thread-index: AcaWxUtSUooUAJ+sTSCg55Dpx2HUugAwUwtQ
From: "Stefan Santesson" <[e-mail]>
To: "Brad Hards" <[e-mail]>, "Sharon Boeyen" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 24 Jun 2006 12:09:56.0039 (UTC) FILETIME=[1B42F570:01C69787]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k5OC9vGD027754
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>

Personally I feel positive about such initiative even though I fear the
volume of debates it might cause. I would like to hear the rest of the
WG on this.

I do acknowledge that we are facing practical problems out there that
the standard can't solve today.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Brad Hards
Sent: den 23 juni 2006 14:03
To: Sharon Boeyen
Cc: [e-mail]
Subject: Re: last call for 3280bis - escape clause

On Friday 23 June 2006 21:12 pm, Sharon Boeyen wrote:
> There should not be any escape clause in 3280bis for any
non-conformant
> behavior. 3280bis is a profile of X.509 - it is not a narrative to
describe
> various types of non-conformant behavior, regardless of what it is.
Perhaps there might be a role for an Informational RFC that explains the

various issues that are a source of concern. Ideally it would provide
some 
guidance on how to deal with the non-conformant behaviour. At the very
least 
it could explain the consequences of particular courses of action.

Brad



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OC4vDm026309; Sat, 24 Jun 2006 05:04:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5OC4vCJ026308; Sat, 24 Jun 2006 05:04:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5OC4sXM026284 for <[e-mail]>; Sat, 24 Jun 2006 05:04:55 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jun 2006 13:04:53 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69786.668350C3"
Subject: RE: last call for 3280bis - escape clause
Date: Sat, 24 Jun 2006 13:04:50 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: last call for 3280bis - escape clause
thread-index: AcaWtewXOniEh36LRe+695QhbjS9hQA0Esgw
From: "Stefan Santesson" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 24 Jun 2006 12:04:53.0184 (UTC) FILETIME=[66BEF400:01C69786]
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_001_01C69786.668350C3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Sharon,

=20

I fully agree. We should not describe any non conformant behavior. I
hope you haven't interpreted my question in that manner.

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: Sharon Boeyen [mailto:[e-mail]]=20
Sent: den 23 juni 2006 13:12
To: Stefan Santesson; Santosh Chokhani; [e-mail]
Subject: RE: last call for 3280bis - escape clause

=20

There should not be any escape clause in 3280bis for any non-conformant
behavior. 3280bis is a profile of X.509 - it is not a narrative to
describe various types of non-conformant behavior, regardless of what it
is.=20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Friday, June 23, 2006 5:28 AM
To: Santosh Chokhani; [e-mail]
Subject: RE: last call for 3280bis - escape clause

	Santosh,

	=20

	Yes, you are correct that the path will validate without any
error in your example.=20

	It will also have an empty set of valid policies. So accepting
the EE certificate policies as valid (using that path) do require some
kind of non-conformant policy checking.

	=20

	I agree on your conclusion. However I have experienced
implementers not feeling sure about this principle. Especially when it
comes to configuration options enabled by an administrative UI and not
just some mode switch in the OS.

	The escape clause in pki4ipsic was driven by this uncertainty.

	=20

	=20

	Stefan Santesson

	Senior Program Manager

	Windows Security, Standards

=09
________________________________


	From: Santosh Chokhani [mailto:[e-mail]]=20
	Sent: den 23 juni 2006 02:48
	To: Stefan Santesson; [e-mail]
	Subject: RE: last call for 3280bis - escape clause

	=20

	Stefan,

	=20

	On disagree with you on 2.  You seem to be asking for 2 and then
saying that it is not valid.

	=20

	A path validation profile (assuming we agree to ignore "require
explicit policy") with setting acceptable policy set to anyPolicy is
valid X.509 and 3280 configuration.  In that case, there will not be a
policy failure and relying party can always make additional checks.  I
encourage you to look at Section J.3 in Annex J of X.509.  If you see
any errors in Annex J, please let me know.

	=20

	As to Standard compliant implementation putting itself in
non-compliant mode, that is always acceptable.  In that mode it will NOT
be standard compliant; that is all.

=09
________________________________


	From: Stefan Santesson [mailto:[e-mail]]=20
	Sent: Thursday, June 22, 2006 8:39 PM
	To: Santosh Chokhani; [e-mail]
	Subject: RE: last call for 3280bis - escape clause

	=20

	Santosh,

	=20

	There are 2 distinct reasons why your approach is not a generic
solution to the problem.

	=20

	1)       The problem is generic and does not only apply to
policy processing. The pki4ipsec issue was e.g. motivated from problems
with EKU settings in existing certificates that does not satisfy new
applications and usages.

	2)       If you need to test for a policy in the end
certificate, that policy will not be valid unless supported by the path,
regardless if policy constraints was set or not.

	=20

	In the perfect world, compliant path processing will always do
the job. In the real world, you may need to tweak the rules to make a
new application fit into an existing infrastructure-

	=20

	The question is still: Can a standards compliant implementation
allow configuration of non conformant modifications to the validation
process, or does that make the implementation as a whole non-conformant.

	=20

	=20

	Stefan Santesson

	Senior Program Manager

	Windows Security, Standards

=09
________________________________


	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Santosh Chokhani
	Sent: den 22 juni 2006 22:59
	To: [e-mail]
	Subject: RE: last call for 3280bis - escape clause

	=20

	Stefan,

	=20

	I agree with sentiments voiced by Steve, Rich, and Sharon.

	=20

	I have a simple solution to your concern from the relying party
viewpoint.  This observation is made with a long-held view of mine (and
no one had provided a convincing logical or business argument) that the
require explicit policy setting is a useless field.  A relying party can
always set acceptable policies to none.  In that scenario, (require
explicit policy) flag not withstanding, path validation will succeed.
Now, the user can examine the end certificate policy.

	=20

	You and I have had this discussion in another context.  The
basic premise is that if some field in the last certificate only is of
interest and the "state" in the path validation process does not impact
it, that need not be path of path validation engine.

	=20

	Thus, you can judiciously use the 3280 Engine and obtain the
result you seek.

=09
________________________________


	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Guida, Richard
[JJCUS]
	Sent: Thursday, June 22, 2006 2:48 PM
	To: Sharon Boeyen; 'Stefan Santesson'; [e-mail]
	Cc: Stephen Kent
	Subject: RE: last call for 3280bis - escape clause

	=20

	Stefan - perhaps I am missing something, but there is nothing
that stops a relying party from writing software that would perform
processing extensions only on CA certs as you propose.  As Sharon
properly notes, that would not be RFC3280 compliant - but a relying
party can choose to be non-compliant if it wishes.  And such
non-compliance only puts the relying party at risk, not others - so that
is a "good thing" relatively speaking.  But in the final analysis, seems
to me that Sharon is absolutely correct (assuming she and I are
interpreting your proposal properly) - unless X.509 is redefined, this
would remain a circumstance of non-compliance.  And so it should be
treated as such.  Very best regards -- Rich

	=20

	=20

	=20

	Richard A. Guida=20
	Director, Information Security=20

	Johnson & Johnson=20
	Room GS8217=20
	410 George Street=20
	New Brunswick, New Jersey  08901=20
	Phone:  [phone]=20

		-----Original Message-----
		From: [e-mail]
[mailto:[e-mail]]On Behalf Of Sharon Boeyen
		Sent: Thursday, June 22, 2006 1:57 PM
		To: 'Stefan Santesson'; [e-mail]
		Cc: Stephen Kent
		Subject: RE: last call for 3280bis - escape clause

		Stefan, if I understand your comment correctly I
strongly believe such an escape clause cannot possibly be added because
this would render 3280bis non-compliant with X.509.=20

		=20

		My understanding of your comment is that the escape
clause would enable a path validation engine to process the certificate
policy OIDs found in CA certificates but ignore those found in EE
certificates. Is that a correct understanding?=20

		=20

		If it is a correct understanding, then any such
implementation is non-conformant to X.509. 3280 is a profile of X.509
and as such can mandate certain optional elements or exclude optional
elements but cannot reverse the mandatory processing from X.509.

		=20

		Apologies if I've misunderstood your question.

		=20

		Cheers,

		Sharon

			-----Original Message-----
			From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
			Sent: Wednesday, June 21, 2006 5:23 PM
			To: [e-mail]
			Cc: Stephen Kent
			Subject: RE: last call for 3280bis - escape
clause

			As a last call comment on RFC 3280bis I would
like to raise the question whether RFC 3280bis should include an escape
clause clearly allowing relying parties to select what validation logic
they deploy on certificate validation.

			=20

			The background is the fact that many deployed
PKIs are misconfigured.2

			One such common misconfiguration is assignment
of certificate policies and their inclusion in CA certificates.

			X.509 path processing requires policies in CA
certificates to reflect the list of EE certificate policies that are
valid for a path. Yet many deployments have included pure CA certificate
policies in CA certificates, policies that are not included in any EE
certificates and as such, policy processing is not possible in such
PKIs.

			=20

			Application wanting to use certificate policies
in such PKI are simply forced to either fail or selectively neglect
certain path processing rules. For a relying party such modification
could be reasonable if the security implications has been well though
through.

			However it is not clear if an implementation
allowing such local configuration could be regarded as standard
compliant.

			=20

			There are more examples where deploying
applications in misconfigured PKIs would need similar measures to work.

			=20

			The pki4ipsec WG recently came to this
conclusion in their PKI profile and this lead to an intense debate which
included core participants from the PKIX WG.

			=20

			The result was that the pki4ipsec profile
included an escape clause as follows:

			=20

			4.1.  X.509 Certificates
			=20
			   Users deploying IKE and IPsec with
certificates have often had little
			   control over the capabilities of CAs
available to them.
			   Implementations of this specification may
include configuration knobs
			   to disable checks required by this
specification in orde!
			 r t
			 o permit
			   use with inflexible and/or noncompliant CAs.
However, all checks on
			   certificates exist for a specific reason
involving the security of
			   the entire system.  Therefore, all checks
MUST be enabled by default.
			   Administrators and users ought to understand
the security purpose for
			   the various checks, and be clear on what
security will be lost by
			   disabling the check.

			=20

			=20

			I'm basically asking if RFC 3280bis path
validation needs a similar escape clause or corresponding clarification
that clearly allows local configuration of the validation logic.

			At least I think it is necessary to clearly
allow such configuration of standards compliant applications as long as
this is not the default functionality.

			=20

			=20

			Stefan Santesson

			Senior Program Manager

			Windows Security, Standards

		=09
________________________________


			From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stephen Kent
			Sent: den 16 juni 2006 22:42
			To: [e-mail]
			Subject: last call for 3280bis

			=20

			Folks,

			=20

			Based on the latest message from David Cooper, I
am initiating last call on "Internet X.509 Public Key Infrastructure,
Certificate and Certificate Revocation List (CRL) Profile"
(http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt> )

			=20

			The last call will last for two weeks. In
deference to the U.S. Independence Dya holiday (which means July 3rd is
a holiday for many folks), all comments must be received by July 5th.

			=20

			Steve


------_=_NextPart_001_01C69786.668350C3
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:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Message</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	mso-list:l0 level2 lfo2;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
tt
	{font-family:"Courier New";}
p.stylecentered, li.stylecentered, div.stylecentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.stylecentered0, li.stylecentered0, div.stylecentered0
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle25
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle26
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle28
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:2036692173;
	mso-list-template-ids:1164602328;}
@list l0:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font =
size=3D2
  color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:navy'>Sharon</span></font></st1:place></st1:City><font size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>,<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I fully agree. We should not =
describe any
non conformant behavior. I hope you haven&#8217;t interpreted my =
question in
that manner.<o:p></o:p></span></font></p>

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Sharon Boeyen
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 23 juni 2006 =
13:12<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Stefan Santesson; =
Santosh
Chokhani; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>There should not be any escape =
clause in
3280bis for any non-conformant behavior. 3280bis is a profile of X.509 - =
it is
not a narrative to describe various types of non-conformant behavior,
regardless of what it is.</span></font> <o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, June 23, =
2006 5:28
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Santosh Chokhani;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Yes, you are correct that the path =
will
validate without any error in your example. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>It will also have an empty set of =
valid
policies. So accepting the EE certificate policies as valid (using that =
path)
do require some kind of non-conformant policy =
checking.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree on your conclusion. However =
I have
experienced implementers not feeling sure about this principle. =
Especially when
it comes to configuration options enabled by an administrative UI and =
not just
some mode switch in the OS.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The escape clause in pki4ipsic was =
driven
by this uncertainty.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Santosh Chokhani
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 23 juni 2006 =
02:48<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Stefan Santesson;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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


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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>On disagree with you on 2. =
&nbsp;You seem
to be asking for 2 and then saying that it is not =
valid.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>A path validation profile (assuming =
we
agree to ignore &quot;require explicit policy&quot;) with setting =
acceptable policy
set to anyPolicy is valid X.509 and 3280 configuration. &nbsp;In that =
case,
there will not be a policy failure and relying party can always make =
additional
checks. &nbsp;I encourage you to look at Section J.3 in Annex J of =
X.509.
&nbsp;If you see any errors in Annex J, please let me =
know.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As to Standard compliant =
implementation
putting itself in non-compliant mode, that is always acceptable. =
&nbsp;In that
mode it will NOT be standard compliant; that is =
all.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Stefan Santesson
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 8:39
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Santosh Chokhani;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are 2 distinct reasons why =
your
approach is not a generic solution to the =
problem.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>1)</span></font><font size=3D1 color=3Dnavy><span =
style=3D'font-size:
7.0pt;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>The problem is generic and does not only apply to policy
processing. The pki4ipsec issue was e.g. motivated from problems with =
EKU
settings in existing certificates that does not satisfy new applications =
and
usages.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>2)</span></font><font size=3D1 color=3Dnavy><span =
style=3D'font-size:
7.0pt;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>If you need to test for a policy in the end certificate, =
that
policy will not be valid unless supported by the path, regardless if =
policy
constraints was set or not.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In the perfect world, compliant =
path
processing will always do the job. In the real world, you may need to =
tweak the
rules to make a new application fit into an existing =
infrastructure-<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The question is still: Can a =
standards
compliant implementation allow configuration of non conformant =
modifications to
the validation process, or does that make the implementation as a whole =
non-conformant.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Santosh Chokhani<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 22 juni 2006 =
22:59<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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


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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree with sentiments voiced by =
Steve,
Rich, and Sharon.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I have a simple solution to your =
concern
from the relying party viewpoint.&nbsp; This observation is made with a
long-held view of mine (and no one had provided a convincing logical or
business argument) that the require explicit policy setting is a useless =
field.
&nbsp;A relying party can always set acceptable policies to none. =
&nbsp;In that
scenario, (require explicit policy) flag not withstanding, path =
validation will
succeed. &nbsp;Now, the user can examine the end certificate =
policy.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>You and I have had this discussion =
in
another context. &nbsp;The basic premise is that if some field in the =
last
certificate only is of interest and the &quot;state&quot; in the path
validation process does not impact it, that need not be path of path =
validation
engine.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thus, you can judiciously use the =
3280
Engine and obtain the result you seek.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Guida, Richard =
[JJCUS]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 2:48
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sharon Boeyen; =
'Stefan
Santesson'; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan - perhaps I am missing =
something,
but there is nothing that stops a relying party from writing software =
that
would perform processing extensions&nbsp;only on CA certs as you =
propose.&nbsp;
As <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Sharon</st1:City></st1:place>
properly notes, that would not be RFC3280 compliant - but a relying =
party can
choose to be non-compliant if it wishes.&nbsp; And such non-compliance =
only
puts the relying party at risk, not others - so that is&nbsp;a =
&quot;good
thing&quot; relatively speaking.&nbsp; But in the final analysis, seems =
to me
that <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Sharon</st1:City></st1:place> is
absolutely correct (assuming she and I are interpreting your proposal
properly)&nbsp;- unless X.509 is redefined, this would remain a =
circumstance of
non-compliance.&nbsp; And so it should be treated as&nbsp;such.&nbsp; =
Very best
regards -- Rich</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Richard A. Guida</span></font></b> <br>
<b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Director, Information Security</span></font></b> =
<o:p></o:p></p>

<p><b><i><font size=3D5 color=3Dred face=3D"Times New Roman"><span =
style=3D'font-size:
18.0pt;color:red;font-weight:bold;font-style:italic'>Johnson &amp; =
Johnson</span></font></i></b>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Room
GS8217</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>410 <st1:address
w:st=3D"on"><st1:Street w:st=3D"on">George Street</st1:Street><font =
size=3D3
 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;font-family:"Times New Roman"'>
 <br>
 </span></font><st1:City w:st=3D"on">New Brunswick</st1:City>, =
<st1:State w:st=3D"on">New
  Jersey</st1:State>&nbsp; <st1:PostalCode =
w:st=3D"on">08901</st1:PostalCode></st1:address></span></font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Phone:&nbsp;
732 524 3785</span></font> <o:p></o:p></p>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]]<b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Sharon Boeyen<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 1:57
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Stefan Santesson';
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan, if I understand your =
comment
correctly I strongly believe such an escape clause cannot possibly be =
added
because this would render 3280bis non-compliant with X.509. =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>My understanding of your comment is =
that
the escape clause would enable a path validation engine to process the
certificate policy OIDs found in CA certificates but ignore those found =
in EE
certificates. Is that a correct understanding? =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If it is a correct understanding, =
then any
such implementation is non-conformant to X.509. 3280 is a profile of =
X.509 and
as such can mandate certain optional elements or exclude optional =
elements but
cannot reverse the mandatory processing from =
X.509.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Apologies if I've misunderstood =
your
question.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

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


</div>

<div>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2
  color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:blue'>Sharon</span></font></st1:City></st1:place><o:p></o:p></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, June 21, =
2006
5:23 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As a last call comment on RFC =
3280bis I
would like to raise the question whether RFC 3280bis should include an =
escape
clause clearly allowing relying parties to select what validation logic =
they
deploy on certificate validation.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The background is the fact that =
many
deployed PKIs are misconfigured.2<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>One such common misconfiguration is
assignment of certificate policies and their inclusion in CA =
certificates.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>X.509 path processing requires =
policies in
CA certificates to reflect the list of EE certificate policies that are =
valid
for a path. Yet many deployments have included pure CA certificate =
policies in
CA certificates, policies that are not included in any EE certificates =
and as
such, policy processing is not possible in such =
PKIs.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Application wanting to use =
certificate
policies in such PKI are simply forced to either fail or selectively =
neglect
certain path processing rules. For a relying party such modification =
could be
reasonable if the security implications has been well though =
through.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>However it is not clear if an
implementation allowing such local configuration could be regarded as =
standard
compliant.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are more examples where =
deploying
applications in misconfigured PKIs would need similar measures to =
work.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The pki4ipsec WG recently came to =
this
conclusion in their PKI profile and this lead to an intense debate which
included core participants from the PKIX =
WG.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The result was that the pki4ipsec =
profile
included an escape clause as follows:<o:p></o:p></span></font></p>

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

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>4.1.&nbsp; X.509 =
Certificates<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Users deploying IKE and IPsec =
with certificates have often had =
little<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; control over the capabilities of =
CAs available to them.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Implementations of this =
specification may include configuration =
knobs<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; to disable checks required by =
this specification in orde!<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> r =
t<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> o =
permit<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; use with inflexible and/or =
noncompliant CAs.&nbsp; However, all checks =
on<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; certificates exist for a =
specific reason involving the security =
of<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the entire system.&nbsp; =
Therefore, all checks MUST be enabled by =
default.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Administrators and users ought =
to understand the security purpose =
for<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the various checks, and be clear =
on what security will be lost =
by<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span e=3D"FONT-SIZE: 10pt" styl!><span
style=3D'font-size:10.0pt'>&nbsp;&nbsp; disabling the =
check.<o:p></o:p></span></font></pre></span>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I'm basically asking if RFC 3280bis =
path
validation needs a similar escape clause or corresponding clarification =
that
clearly allows local configuration of the validation =
logic.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>At least I think it is necessary to
clearly allow such configuration of standards compliant applications as =
long as
this is not the default functionality.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 16 juni 2006 =
22:42<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> last call for =
3280bis</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Folks,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Based on the latest message from David Cooper, I am initiating =
last
call on</span></font><font size=3D2><span style=3D'font-size:10.0pt'>
&quot;Internet X.509 Public Key Infrastructure, Certificate and =
Certificate
Revocation List (CRL) Profile&quot;</span></font><tt><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt'> =
(</span></font></tt><a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt=
"><font
size=3D2><span =
style=3D'font-size:10.0pt'>http://ietf.org/internet-drafts/draft-ietf-pki=
x-rfc3280bis-03.txt</span></font></a><font
size=3D2><span style=3D'font-size:10.0pt'>)</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>The last call will last for two weeks. In deference to the U.S.
Independence Dya holiday (which means July 3rd is a holiday for many =
folks),
all comments must be received by July 5th.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Steve</span></font><o:p></o:p></p>

</div>

</blockquote>

</blockquote>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C69786.668350C3--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NC3e1F069973; Fri, 23 Jun 2006 05:03:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5NC3e7g069972; Fri, 23 Jun 2006 05:03:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from omta05ps.mx.bigpond.com (omta05ps.mx.bigpond.com [144.140.83.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NC3dAY069950 for <[e-mail]>; Fri, 23 Jun 2006 05:03:40 -0700 (MST) (envelope-from [e-mail])
Received: from prionotes.cuneata.net ([61.9.204.42]) by omta05ps.mx.bigpond.com with ESMTP id <[e-mail]>; Fri, 23 Jun 2006 12:03:28 +0000
From: Brad Hards <[e-mail]>
To: Sharon Boeyen <[e-mail]>
Subject: Re: last call for 3280bis - escape clause
Date: Fri, 23 Jun 2006 22:02:43 +1000
User-Agent: KMail/1.9.1
Cc: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart8723954.v22oNSQp9r"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[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>

--nextPart8723954.v22oNSQp9r
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 23 June 2006 21:12 pm, Sharon Boeyen wrote:
> There should not be any escape clause in 3280bis for any non-conformant
> behavior. 3280bis is a profile of X.509 - it is not a narrative to descri=
be
> various types of non-conformant behavior, regardless of what it is.
Perhaps there might be a role for an Informational RFC that explains the=20
various issues that are a source of concern. Ideally it would provide some=
=20
guidance on how to deal with the non-conformant behaviour. At the very leas=
t=20
it could explain the consequences of particular courses of action.

Brad

--nextPart8723954.v22oNSQp9r
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBEm9hrGwwszQ/PZzgRAsYHAJ97yDRdQCj1Tsw6xGL+ZiJGZDCDMACfRt3k
kVrwNyKjMIhq92lvDgd2xdU=
=o2Dn
-----END PGP SIGNATURE-----

--nextPart8723954.v22oNSQp9r--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NBiOrt065702; Fri, 23 Jun 2006 04:44:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5NBiOb2065701; Fri, 23 Jun 2006 04:44:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NBiNHZ065677 for <[e-mail]>; Fri, 23 Jun 2006 04:44:24 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696BA.DCDC9215"
Subject: RE: last call for 3280bis - escape clause
Date: Fri, 23 Jun 2006 04:44:17 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: last call for 3280bis - escape clause
Thread-Index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsAAAeBmuAAAJmXEAAN+MPwAAkZyFA=
From: "Santosh Chokhani" <[e-mail]>
To: <[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>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C696BA.DCDC9215
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

We seem to be converging.

=20

The way the relying party should see it and that is why I find the path
processing to be compliant with X.509 and 3280 is as follows:

=20

The path is good for no policies.  The relying party accepts a path that
is not good for any policy and makes an additional check (which the
standards permit) to see if the end certificate has the desired policy.

=20

I hope this clarifies the standard compliance.

________________________________

From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Friday, June 23, 2006 5:28 AM
To: Santosh Chokhani; [e-mail]
Subject: RE: last call for 3280bis - escape clause

=20

Santosh,

=20

Yes, you are correct that the path will validate without any error in
your example.=20

It will also have an empty set of valid policies. So accepting the EE
certificate policies as valid (using that path) do require some kind of
non-conformant policy checking.

=20

I agree on your conclusion. However I have experienced implementers not
feeling sure about this principle. Especially when it comes to
configuration options enabled by an administrative UI and not just some
mode switch in the OS.

The escape clause in pki4ipsic was driven by this uncertainty.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: Santosh Chokhani [mailto:[e-mail]]=20
Sent: den 23 juni 2006 02:48
To: Stefan Santesson; [e-mail]
Subject: RE: last call for 3280bis - escape clause

=20

Stefan,

=20

On disagree with you on 2.  You seem to be asking for 2 and then saying
that it is not valid.

=20

A path validation profile (assuming we agree to ignore "require explicit
policy") with setting acceptable policy set to anyPolicy is valid X.509
and 3280 configuration.  In that case, there will not be a policy
failure and relying party can always make additional checks.  I
encourage you to look at Section J.3 in Annex J of X.509.  If you see
any errors in Annex J, please let me know.

=20

As to Standard compliant implementation putting itself in non-compliant
mode, that is always acceptable.  In that mode it will NOT be standard
compliant; that is all.

________________________________

From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Thursday, June 22, 2006 8:39 PM
To: Santosh Chokhani; [e-mail]
Subject: RE: last call for 3280bis - escape clause

=20

Santosh,

=20

There are 2 distinct reasons why your approach is not a generic solution
to the problem.

=20

1)       The problem is generic and does not only apply to policy
processing. The pki4ipsec issue was e.g. motivated from problems with
EKU settings in existing certificates that does not satisfy new
applications and usages.

2)       If you need to test for a policy in the end certificate, that
policy will not be valid unless supported by the path, regardless if
policy constraints was set or not.

=20

In the perfect world, compliant path processing will always do the job.
In the real world, you may need to tweak the rules to make a new
application fit into an existing infrastructure-

=20

The question is still: Can a standards compliant implementation allow
configuration of non conformant modifications to the validation process,
or does that make the implementation as a whole non-conformant.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 22:59
To: [e-mail]
Subject: RE: last call for 3280bis - escape clause

=20

Stefan,

=20

I agree with sentiments voiced by Steve, Rich, and Sharon.

=20

I have a simple solution to your concern from the relying party
viewpoint.  This observation is made with a long-held view of mine (and
no one had provided a convincing logical or business argument) that the
require explicit policy setting is a useless field.  A relying party can
always set acceptable policies to none.  In that scenario, (require
explicit policy) flag not withstanding, path validation will succeed.
Now, the user can examine the end certificate policy.

=20

You and I have had this discussion in another context.  The basic
premise is that if some field in the last certificate only is of
interest and the "state" in the path validation process does not impact
it, that need not be path of path validation engine.

=20

Thus, you can judiciously use the 3280 Engine and obtain the result you
seek.

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Guida, Richard [JJCUS]
Sent: Thursday, June 22, 2006 2:48 PM
To: Sharon Boeyen; 'Stefan Santesson'; [e-mail]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

=20

Stefan - perhaps I am missing something, but there is nothing that stops
a relying party from writing software that would perform processing
extensions only on CA certs as you propose.  As Sharon properly notes,
that would not be RFC3280 compliant - but a relying party can choose to
be non-compliant if it wishes.  And such non-compliance only puts the
relying party at risk, not others - so that is a "good thing" relatively
speaking.  But in the final analysis, seems to me that Sharon is
absolutely correct (assuming she and I are interpreting your proposal
properly) - unless X.509 is redefined, this would remain a circumstance
of non-compliance.  And so it should be treated as such.  Very best
regards -- Rich

=20

=20

=20

Richard A. Guida=20
Director, Information Security=20

Johnson & Johnson=20
Room GS8217=20
410 George Street=20
New Brunswick, New Jersey  08901=20
Phone:  [phone]=20

	-----Original Message-----
	From: [e-mail]
[mailto:[e-mail]]On Behalf Of Sharon Boeyen
	Sent: Thursday, June 22, 2006 1:57 PM
	To: 'Stefan Santesson'; [e-mail]
	Cc: Stephen Kent
	Subject: RE: last call for 3280bis - escape clause

	Stefan, if I understand your comment correctly I strongly
believe such an escape clause cannot possibly be added because this
would render 3280bis non-compliant with X.509.=20

	=20

	My understanding of your comment is that the escape clause would
enable a path validation engine to process the certificate policy OIDs
found in CA certificates but ignore those found in EE certificates. Is
that a correct understanding?=20

	=20

	If it is a correct understanding, then any such implementation
is non-conformant to X.509. 3280 is a profile of X.509 and as such can
mandate certain optional elements or exclude optional elements but
cannot reverse the mandatory processing from X.509.

	=20

	Apologies if I've misunderstood your question.

	=20

	Cheers,

	Sharon

		-----Original Message-----
		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
		Sent: Wednesday, June 21, 2006 5:23 PM
		To: [e-mail]
		Cc: Stephen Kent
		Subject: RE: last call for 3280bis - escape clause

		As a last call comment on RFC 3280bis I would like to
raise the question whether RFC 3280bis should include an escape clause
clearly allowing relying parties to select what validation logic they
deploy on certificate validation.

		=20

		The background is the fact that many deployed PKIs are
misconfigured.2

		One such common misconfiguration is assignment of
certificate policies and their inclusion in CA certificates.

		X.509 path processing requires policies in CA
certificates to reflect the list of EE certificate policies that are
valid for a path. Yet many deployments have included pure CA certificate
policies in CA certificates, policies that are not included in any EE
certificates and as such, policy processing is not possible in such
PKIs.

		=20

		Application wanting to use certificate policies in such
PKI are simply forced to either fail or selectively neglect certain path
processing rules. For a relying party such modification could be
reasonable if the security implications has been well though through.

		However it is not clear if an implementation allowing
such local configuration could be regarded as standard compliant.

		=20

		There are more examples where deploying applications in
misconfigured PKIs would need similar measures to work.

		=20

		The pki4ipsec WG recently came to this conclusion in
their PKI profile and this lead to an intense debate which included core
participants from the PKIX WG.

		=20

		The result was that the pki4ipsec profile included an
escape clause as follows:

		=20

		4.1.  X.509 Certificates
		=20
		   Users deploying IKE and IPsec with certificates have
often had little
		   control over the capabilities of CAs available to
them.
		   Implementations of this specification may include
configuration knobs
		   to disable checks required by this specification in
orde!
		 r t
		 o permit
		   use with inflexible and/or noncompliant CAs.
However, all checks on
		   certificates exist for a specific reason involving
the security of
		   the entire system.  Therefore, all checks MUST be
enabled by default.
		   Administrators and users ought to understand the
security purpose for
		   the various checks, and be clear on what security
will be lost by
		   disabling the check.

		=20

		=20

		I'm basically asking if RFC 3280bis path validation
needs a similar escape clause or corresponding clarification that
clearly allows local configuration of the validation logic.

		At least I think it is necessary to clearly allow such
configuration of standards compliant applications as long as this is not
the default functionality.

		=20

		=20

		Stefan Santesson

		Senior Program Manager

		Windows Security, Standards

	=09
________________________________


		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stephen Kent
		Sent: den 16 juni 2006 22:42
		To: [e-mail]
		Subject: last call for 3280bis

		=20

		Folks,

		=20

		Based on the latest message from David Cooper, I am
initiating last call on "Internet X.509 Public Key Infrastructure,
Certificate and Certificate Revocation List (CRL) Profile"
(http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt> )

		=20

		The last call will last for two weeks. In deference to
the U.S. Independence Dya holiday (which means July 3rd is a holiday for
many folks), all comments must be received by July 5th.

		=20

		Steve


------_=_NextPart_001_01C696BA.DCDC9215
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:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Message</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo4;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo4;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
tt
	{font-family:"Courier New";}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.stylecentered0, li.stylecentered0, div.stylecentered0
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.stylecentered00, li.stylecentered00, div.stylecentered00
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle25
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle26
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle27
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle29
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:361246706;
	mso-list-type:hybrid;
	mso-list-template-ids:9974032 67698705 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l2:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l2:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l2:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l2:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l2:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l2:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l2:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l2:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l2:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

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


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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>We seem to be =
converging.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The way the relying party should =
see it
and that is why I find the path processing to be compliant with X.509 =
and 3280
is as follows:<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The path is good for no =
policies.&nbsp; The
relying party accepts a path that is not good for any policy and makes =
an
additional check (which the standards permit) to see if the end =
certificate has
the desired policy.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I hope this clarifies the standard
compliance.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Stefan Santesson
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, June 23, =
2006 5:28
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Santosh Chokhani;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Yes, you are correct that the path =
will
validate without any error in your example. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>It will also have an empty set of =
valid
policies. So accepting the EE certificate policies as valid (using that =
path)
do require some kind of non-conformant policy =
checking.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree on your conclusion. However =
I have
experienced implementers not feeling sure about this principle. =
Especially when
it comes to configuration options enabled by an administrative UI and =
not just
some mode switch in the OS.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The escape clause in pki4ipsic was =
driven
by this uncertainty.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Santosh Chokhani
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 23 juni 2006 =
02:48<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Stefan Santesson;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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


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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>On disagree with you on 2. =
&nbsp;You seem
to be asking for 2 and then saying that it is not =
valid.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>A path validation profile (assuming =
we
agree to ignore &#8220;require explicit policy&#8221;) with setting =
acceptable
policy set to anyPolicy is valid X.509 and 3280 configuration. &nbsp;In =
that
case, there will not be a policy failure and relying party can always =
make
additional checks. &nbsp;I encourage you to look at Section J.3 in Annex =
J of
X.509. &nbsp;If you see any errors in Annex J, please let me =
know.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As to Standard compliant =
implementation
putting itself in non-compliant mode, that is always acceptable. =
&nbsp;In that
mode it will NOT be standard compliant; that is =
all.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Stefan Santesson
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 8:39
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Santosh Chokhani;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are 2 distinct reasons why =
your
approach is not a generic solution to the =
problem.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 =
lfo6'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>1)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>The problem is generic and does not only apply to policy
processing. The pki4ipsec issue was e.g. motivated from problems with =
EKU
settings in existing certificates that does not satisfy new applications =
and
usages.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 =
lfo6'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>2)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>If you need to test for a policy in the end certificate, =
that
policy will not be valid unless supported by the path, regardless if =
policy
constraints was set or not.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In the perfect world, compliant =
path
processing will always do the job. In the real world, you may need to =
tweak the
rules to make a new application fit into an existing =
infrastructure-<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The question is still: Can a =
standards
compliant implementation allow configuration of non conformant =
modifications to
the validation process, or does that make the implementation as a whole
non-conformant.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Santosh Chokhani<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 22 juni 2006 =
22:59<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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


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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree with sentiments voiced by =
Steve,
Rich, and Sharon.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I have a simple solution to your =
concern
from the relying party viewpoint.&nbsp; This observation is made with a =
long-held
view of mine (and no one had provided a convincing logical or business
argument) that the require explicit policy setting is a useless field. =
&nbsp;A
relying party can always set acceptable policies to none. &nbsp;In that
scenario, (require explicit policy) flag not withstanding, path =
validation will
succeed. &nbsp;Now, the user can examine the end certificate =
policy.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>You and I have had this discussion =
in
another context. &nbsp;The basic premise is that if some field in the =
last
certificate only is of interest and the &#8220;state&#8221; in the path
validation process does not impact it, that need not be path of path =
validation
engine.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thus, you can judiciously use the =
3280
Engine and obtain the result you seek.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Guida, Richard =
[JJCUS]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 2:48
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sharon Boeyen; =
'Stefan
Santesson'; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan - perhaps I am missing =
something,
but there is nothing that stops a relying party from writing software =
that
would perform processing extensions&nbsp;only on CA certs as you =
propose.&nbsp;
As <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Sharon</st1:City></st1:place>
properly notes, that would not be RFC3280 compliant - but a relying =
party can
choose to be non-compliant if it wishes.&nbsp; And such non-compliance =
only
puts the relying party at risk, not others - so that is&nbsp;a =
&quot;good
thing&quot; relatively speaking.&nbsp; But in the final analysis, seems =
to me
that <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Sharon</st1:City></st1:place> is
absolutely correct (assuming she and I are interpreting your proposal
properly)&nbsp;- unless X.509 is redefined, this would remain a =
circumstance of
non-compliance.&nbsp; And so it should be treated as&nbsp;such.&nbsp; =
Very best
regards -- Rich</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Richard A. Guida</span></font></b> <br>
<b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Director, Information Security</span></font></b> =
<o:p></o:p></p>

<p><b><i><font size=3D5 color=3Dred face=3D"Times New Roman"><span =
style=3D'font-size:
18.0pt;color:red;font-weight:bold;font-style:italic'>Johnson &amp; =
Johnson</span></font></i></b>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Room
GS8217</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>410 <st1:address
w:st=3D"on"><st1:Street w:st=3D"on">George Street</st1:Street><font =
size=3D3
 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;font-family:"Times New Roman"'>
 <br>
 </span></font><st1:City w:st=3D"on">New Brunswick</st1:City>, =
<st1:State w:st=3D"on">New
  Jersey</st1:State>&nbsp; <st1:PostalCode =
w:st=3D"on">08901</st1:PostalCode></st1:address></span></font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Phone:&nbsp;
732 524 3785</span></font> <o:p></o:p></p>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]]<b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Sharon Boeyen<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 1:57
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Stefan Santesson';
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan, if I understand your =
comment
correctly I strongly believe such an escape clause cannot possibly be =
added
because this would render 3280bis non-compliant with X.509. =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>My understanding of your comment is =
that
the escape clause would enable a path validation engine to process the
certificate policy OIDs found in CA certificates but ignore those found =
in EE
certificates. Is that a correct understanding? =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If it is a correct understanding, =
then any
such implementation is non-conformant to X.509. 3280 is a profile of =
X.509 and
as such can mandate certain optional elements or exclude optional =
elements but
cannot reverse the mandatory processing from =
X.509.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Apologies if I've misunderstood =
your
question.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

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


</div>

<div>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2
  color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:blue'>Sharon</span></font></st1:City></st1:place><o:p></o:p></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, June 21, =
2006
5:23 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As a last call comment on RFC =
3280bis I
would like to raise the question whether RFC 3280bis should include an =
escape
clause clearly allowing relying parties to select what validation logic =
they deploy
on certificate validation.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The background is the fact that =
many
deployed PKIs are misconfigured.2<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>One such common misconfiguration is
assignment of certificate policies and their inclusion in CA =
certificates.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>X.509 path processing requires =
policies in
CA certificates to reflect the list of EE certificate policies that are =
valid
for a path. Yet many deployments have included pure CA certificate =
policies in
CA certificates, policies that are not included in any EE certificates =
and as
such, policy processing is not possible in such =
PKIs.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Application wanting to use =
certificate
policies in such PKI are simply forced to either fail or selectively =
neglect
certain path processing rules. For a relying party such modification =
could be
reasonable if the security implications has been well though =
through.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>However it is not clear if an
implementation allowing such local configuration could be regarded as =
standard
compliant.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are more examples where =
deploying
applications in misconfigured PKIs would need similar measures to =
work.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The pki4ipsec WG recently came to =
this
conclusion in their PKI profile and this lead to an intense debate which
included core participants from the PKIX =
WG.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The result was that the pki4ipsec =
profile
included an escape clause as follows:<o:p></o:p></span></font></p>

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

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>4.1.&nbsp; X.509 =
Certificates<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Users deploying IKE and IPsec =
with certificates have often had =
little<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; control over the capabilities of =
CAs available to them.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Implementations of this =
specification may include configuration =
knobs<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; to disable checks required by =
this specification in orde!<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> r =
t<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> o =
permit<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; use with inflexible and/or =
noncompliant CAs.&nbsp; However, all checks =
on<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; certificates exist for a =
specific reason involving the security =
of<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the entire system.&nbsp; =
Therefore, all checks MUST be enabled by =
default.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Administrators and users ought =
to understand the security purpose =
for<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the various checks, and be clear =
on what security will be lost =
by<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span styl! e=3D"FONT-SIZE: 10pt"><span
style=3D'font-size:10.0pt'>&nbsp;&nbsp; disabling the =
check.<o:p></o:p></span></font></pre></span>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I'm basically asking if RFC 3280bis =
path
validation needs a similar escape clause or corresponding clarification =
that
clearly allows local configuration of the validation =
logic.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>At least I think it is necessary to
clearly allow such configuration of standards compliant applications as =
long as
this is not the default functionality.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 16 juni 2006 =
22:42<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> last call for =
3280bis</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Folks,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Based on the latest message from David Cooper, I am initiating =
last
call on</span></font><font size=3D2><span style=3D'font-size:10.0pt'>
&quot;Internet X.509 Public Key Infrastructure, Certificate and =
Certificate
Revocation List (CRL) Profile&quot;</span></font><tt><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt'> =
(</span></font></tt><a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt=
"><font
size=3D2><span =
style=3D'font-size:10.0pt'>http://ietf.org/internet-drafts/draft-ietf-pki=
x-rfc3280bis-03.txt</span></font></a><font
size=3D2><span style=3D'font-size:10.0pt'>)</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>The last call will last for two weeks. In deference to the U.S.
Independence Dya holiday (which means July 3rd is a holiday for many =
folks),
all comments must be received by July 5th.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Steve</span></font><o:p></o:p></p>

</div>

</blockquote>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C696BA.DCDC9215--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NBCRZN058181; Fri, 23 Jun 2006 04:12:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5NBCRoe058180; Fri, 23 Jun 2006 04:12:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sottsym2.entrust.com (sottsym2.entrust.com [216.191.252.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5NBCPir058132 for <[e-mail]>; Fri, 23 Jun 2006 04:12:25 -0700 (MST) (envelope-from [e-mail])
Received: from sottmxsecs3.entrust.com (unknown [216.191.252.14]) by sottsym2.entrust.com (Symantec Mail Security) with SMTP id D0D1811F6 for <[e-mail]>; Fri, 23 Jun 2006 07:12:19 -0400 (EDT)
Received: (qmail 28716 invoked from network); 23 Jun 2006 11:12:19 -0000
Received: from [e-mail] by sottmxsecs3.entrust.com with EntrustECS-Server-7.4;23 Jun 2006 11:12:19 -0000
Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 23 Jun 2006 11:12:17 -0000
Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id <M0M5CKD1>; Fri, 23 Jun 2006 07:12:18 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Santosh Chokhani <[e-mail]>, [e-mail]
Subject: RE: last call for 3280bis - escape clause
Date: Fri, 23 Jun 2006 07:12:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696B5.8CC0B636"
X-Brightmail-Tracker: AAAAAA==
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_01C696B5.8CC0B636
Content-Type: text/plain

There should not be any escape clause in 3280bis for any non-conformant
behavior. 3280bis is a profile of X.509 - it is not a narrative to describe
various types of non-conformant behavior, regardless of what it is. 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Friday, June 23, 2006 5:28 AM
To: Santosh Chokhani; [e-mail]
Subject: RE: last call for 3280bis - escape clause



Santosh,

 

Yes, you are correct that the path will validate without any error in your
example. 

It will also have an empty set of valid policies. So accepting the EE
certificate policies as valid (using that path) do require some kind of
non-conformant policy checking.

 

I agree on your conclusion. However I have experienced implementers not
feeling sure about this principle. Especially when it comes to configuration
options enabled by an administrative UI and not just some mode switch in the
OS.

The escape clause in pki4ipsic was driven by this uncertainty.

 

 

Stefan Santesson

Senior Program Manager

Windows Security, Standards


  _____  


From: Santosh Chokhani [mailto:[e-mail]] 
Sent: den 23 juni 2006 02:48
To: Stefan Santesson; [e-mail]
Subject: RE: last call for 3280bis - escape clause

 

Stefan,

 

On disagree with you on 2.  You seem to be asking for 2 and then saying that
it is not valid.

 

A path validation profile (assuming we agree to ignore "require explicit
policy") with setting acceptable policy set to anyPolicy is valid X.509 and
3280 configuration.  In that case, there will not be a policy failure and
relying party can always make additional checks.  I encourage you to look at
Section J.3 in Annex J of X.509.  If you see any errors in Annex J, please
let me know.

 

As to Standard compliant implementation putting itself in non-compliant
mode, that is always acceptable.  In that mode it will NOT be standard
compliant; that is all.


  _____  


From: Stefan Santesson [mailto:[e-mail]] 
Sent: Thursday, June 22, 2006 8:39 PM
To: Santosh Chokhani; [e-mail]
Subject: RE: last call for 3280bis - escape clause

 

Santosh,

 

There are 2 distinct reasons why your approach is not a generic solution to
the problem.

 

1)       The problem is generic and does not only apply to policy
processing. The pki4ipsec issue was e.g. motivated from problems with EKU
settings in existing certificates that does not satisfy new applications and
usages.

2)       If you need to test for a policy in the end certificate, that
policy will not be valid unless supported by the path, regardless if policy
constraints was set or not.

 

In the perfect world, compliant path processing will always do the job. In
the real world, you may need to tweak the rules to make a new application
fit into an existing infrastructure-

 

The question is still: Can a standards compliant implementation allow
configuration of non conformant modifications to the validation process, or
does that make the implementation as a whole non-conformant.

 

 

Stefan Santesson

Senior Program Manager

Windows Security, Standards


  _____  


From: [e-mail] [mailto:[e-mail]] On
Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 22:59
To: [e-mail]
Subject: RE: last call for 3280bis - escape clause

 

Stefan,

 

I agree with sentiments voiced by Steve, Rich, and Sharon.

 

I have a simple solution to your concern from the relying party viewpoint.
This observation is made with a long-held view of mine (and no one had
provided a convincing logical or business argument) that the require
explicit policy setting is a useless field.  A relying party can always set
acceptable policies to none.  In that scenario, (require explicit policy)
flag not withstanding, path validation will succeed.  Now, the user can
examine the end certificate policy.

 

You and I have had this discussion in another context.  The basic premise is
that if some field in the last certificate only is of interest and the
"state" in the path validation process does not impact it, that need not be
path of path validation engine.

 

Thus, you can judiciously use the 3280 Engine and obtain the result you
seek.


  _____  


From: [e-mail] [mailto:[e-mail]] On
Behalf Of Guida, Richard [JJCUS]
Sent: Thursday, June 22, 2006 2:48 PM
To: Sharon Boeyen; 'Stefan Santesson'; [e-mail]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

 

Stefan - perhaps I am missing something, but there is nothing that stops a
relying party from writing software that would perform processing extensions
only on CA certs as you propose.  As Sharon properly notes, that would not
be RFC3280 compliant - but a relying party can choose to be non-compliant if
it wishes.  And such non-compliance only puts the relying party at risk, not
others - so that is a "good thing" relatively speaking.  But in the final
analysis, seems to me that Sharon is absolutely correct (assuming she and I
are interpreting your proposal properly) - unless X.509 is redefined, this
would remain a circumstance of non-compliance.  And so it should be treated
as such.  Very best regards -- Rich

 

 

 

Richard A. Guida 
Director, Information Security 

Johnson & Johnson 
Room GS8217 
410 George Street 
New Brunswick, New Jersey  08901 
Phone:  [phone] 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Sharon Boeyen
Sent: Thursday, June 22, 2006 1:57 PM
To: 'Stefan Santesson'; [e-mail]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

Stefan, if I understand your comment correctly I strongly believe such an
escape clause cannot possibly be added because this would render 3280bis
non-compliant with X.509. 

 

My understanding of your comment is that the escape clause would enable a
path validation engine to process the certificate policy OIDs found in CA
certificates but ignore those found in EE certificates. Is that a correct
understanding? 

 

If it is a correct understanding, then any such implementation is
non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate
certain optional elements or exclude optional elements but cannot reverse
the mandatory processing from X.509.

 

Apologies if I've misunderstood your question.

 

Cheers,

Sharon

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Wednesday, June 21, 2006 5:23 PM
To: [e-mail]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

As a last call comment on RFC 3280bis I would like to raise the question
whether RFC 3280bis should include an escape clause clearly allowing relying
parties to select what validation logic they deploy on certificate
validation.

 

The background is the fact that many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and
their inclusion in CA certificates.

X.509 path processing requires policies in CA certificates to reflect the
list of EE certificate policies that are valid for a path. Yet many
deployments have included pure CA certificate policies in CA certificates,
policies that are not included in any EE certificates and as such, policy
processing is not possible in such PKIs.

 

Application wanting to use certificate policies in such PKI are simply
forced to either fail or selectively neglect certain path processing rules.
For a relying party such modification could be reasonable if the security
implications has been well though through.

However it is not clear if an implementation allowing such local
configuration could be regarded as standard compliant.

 

There are more examples where deploying applications in misconfigured PKIs
would need similar measures to work.

 

The pki4ipsec WG recently came to this conclusion in their PKI profile and
this lead to an intense debate which included core participants from the
PKIX WG.

 

The result was that the pki4ipsec profile included an escape clause as
follows:

 

4.1.  X.509 Certificates
 
   Users deploying IKE and IPsec with certificates have often had little
   control over the capabilities of CAs available to them.
   Implementations of this specification may include configuration knobs
   to disable checks required by this specification in orde!
 r t
 o permit
   use with inflexible and/or noncompliant CAs.  However, all checks on
   certificates exist for a specific reason involving the security of
   the entire system.  Therefore, all checks MUST be enabled by default.
   Administrators and users ought to understand the security purpose for
   the various checks, and be clear on what security will be lost by
   disabling the check.

 

 

I'm basically asking if RFC 3280bis path validation needs a similar escape
clause or corresponding clarification that clearly allows local
configuration of the validation logic.

At least I think it is necessary to clearly allow such configuration of
standards compliant applications as long as this is not the default
functionality.

 

 

Stefan Santesson

Senior Program Manager

Windows Security, Standards


  _____  


From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: den 16 juni 2006 22:42
To: [e-mail]
Subject: last call for 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating last call on
"Internet X.509 Public Key Infrastructure, Certificate and Certificate
Revocation List (CRL) Profile" (
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt>
http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence
Dya holiday (which means July 3rd is a holiday for many folks), all comments
must be received by July 5th.

 

Steve


------_=_NextPart_001_01C696B5.8CC0B636
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType name=3D"Street"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTag=
Type><o:SmartTagType=20
name=3D"PostalCode"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTag=
Type><o:SmartTagType=20
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTag=
Type><o:SmartTagType=20
name=3D"address"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTag=
Type><o:SmartTagType=20
name=3D"State"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTag=
Type><o:SmartTagType=20
name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTag=
Type><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; =
}
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
H1 {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt 0.3in; =
TEXT-INDENT: -0.3in; FONT-FAMILY: Arial; mso-list: l0 level1 lfo2
}
H2 {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 12pt 0in 3pt 0.4in; =
TEXT-INDENT: -0.4in; FONT-FAMILY: Arial; mso-list: l0 level2 lfo2
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: =
auto
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
TT {
	FONT-FAMILY: "Courier New"
}
P.stylecentered {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
LI.stylecentered {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
DIV.stylecentered {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
P.stylecentered0 {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
LI.stylecentered0 {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
DIV.stylecentered0 {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
SPAN.EmailStyle22 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle23 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle24 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle25 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle27 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV><SPAN class=3D177290911-23062006><FONT face=3DArial =
color=3D#0000ff size=3D2>There 
should not be any escape clause in 3280bis for any non-conformant =
behavior.=20
3280bis is a profile of X.509 - it is not a narrative to describe =
various types=20
of non-conformant behavior, regardless of what it is.</FONT></SPAN>
<DIV></DIV><FONT face=3DTahoma size=3D2>-----Original =
Message-----<BR><B>From:</B>=20
[e-mail] [mailto:[e-mail]] =
<B>On Behalf=20
Of </B>Stefan Santesson<BR><B>Sent:</B> Friday, June 23, 2006 5:28=20
AM<BR><B>To:</B> Santosh Chokhani; [e-mail]<BR><B>Subject:</B> =
RE: last=20
call for 3280bis - escape clause<BR><BR></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Santosh,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Yes, you =
are correct=20
  that the path will validate without any error in your example.=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">It will =
also have an=20
  empty set of valid policies. So accepting the EE certificate policies =
as valid=20
  (using that path) do require some kind of non-conformant policy=20
  checking.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I agree on =
your=20
  conclusion. However I have experienced implementers not feeling sure =
about=20
  this principle. Especially when it comes to configuration options =
enabled by=20
  an administrative UI and not just some mode switch in the=20
  OS.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The escape =
clause in=20
  pki4ipsic was driven by this =
uncertainty.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=3DMsoNormal><STRONG><B><FONT face=3DArial color=3Dmaroon =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">Stefan=20
  Santesson</SPAN></FONT></B></STRONG><FONT color=3Dnavy><SPAN=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3D#400040 =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: Arial">Senior =
Program=20
  Manager</SPAN></FONT><FONT color=3Dnavy><SPAN=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><STRONG><B><FONT face=3DArial color=3D#400040 =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: Arial">Windows =
Security,=20
  Standards</SPAN></FONT></B></STRONG><o:p></o:p></P></DIV>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Santosh=20
  Chokhani [mailto:[e-mail]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> den 23 juni 2006 =
02:48<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Stefan Santesson;=20
  [e-mail]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B>=20
  RE: last call for 3280bis - escape =
clause</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Stefan,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">On =
disagree with you=20
  on 2. &nbsp;You seem to be asking for 2 and then saying that it is =
not=20
  valid.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">A path =
validation=20
  profile (assuming we agree to ignore "require explicit policy") with =
setting=20
  acceptable policy set to anyPolicy is valid X.509 and 3280 =
configuration.=20
  &nbsp;In that case, there will not be a policy failure and relying =
party can=20
  always make additional checks. &nbsp;I encourage you to look at =
Section J.3 in=20
  Annex J of X.509. &nbsp;If you see any errors in Annex J, please let =
me=20
  know.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As to =
Standard=20
  compliant implementation putting itself in non-compliant mode, that =
is always=20
  acceptable. &nbsp;In that mode it will NOT be standard compliant; =
that is=20
  all.<o:p></o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Stefan=20
  Santesson [mailto:[e-mail]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, June 22, 2006 =
8:39=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Santosh =
Chokhani;=20
  [e-mail]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B>=20
  RE: last call for 3280bis - escape =
clause</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Santosh,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">There are =
2 distinct=20
  reasons why your approach is not a generic solution to the=20
  problem.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l1 =
level1 lfo4"><![if !supportLists]><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  style=3D"mso-list: Ignore">1)<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
color=3Dnavy=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">The=20
  problem is generic and does not only apply to policy processing. The =
pki4ipsec=20
  issue was e.g. motivated from problems with EKU settings in existing=20
  certificates that does not satisfy new applications and=20
  usages.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l1 =
level1 lfo4"><![if !supportLists]><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  style=3D"mso-list: Ignore">2)<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
color=3Dnavy=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">If you=20
  need to test for a policy in the end certificate, that policy will =
not be=20
  valid unless supported by the path, regardless if policy constraints =
was set=20
  or not.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In the =
perfect world,=20
  compliant path processing will always do the job. In the real world, =
you may=20
  need to tweak the rules to make a new application fit into an =
existing=20
  infrastructure-<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The =
question is=20
  still: Can a standards compliant implementation allow configuration =
of non=20
  conformant modifications to the validation process, or does that make =
the=20
  implementation as a whole =
non-conformant.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=3DMsoNormal><STRONG><B><FONT face=3DArial color=3Dmaroon =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: Arial">Stefan=20
  Santesson</SPAN></FONT></B></STRONG><FONT color=3Dnavy><SPAN=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3D#400040 =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: Arial">Senior =
Program=20
  Manager</SPAN></FONT><FONT color=3Dnavy><SPAN=20
  style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><STRONG><B><FONT face=3DArial color=3D#400040 =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: Arial">Windows =
Security,=20
  Standards</SPAN></FONT></B></STRONG><o:p></o:p></P></DIV>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  [e-mail] [mailto:[e-mail]] =
<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Santosh =
Chokhani<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> den 22 juni 2006 =
22:59<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
[e-mail]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: last call for =
3280bis -=20
  escape clause</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Stefan,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I agree =
with=20
  sentiments voiced by Steve, Rich, and =
Sharon.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I have a =
simple=20
  solution to your concern from the relying party viewpoint.&nbsp; This =

  observation is made with a long-held view of mine (and no one had =
provided a=20
  convincing logical or business argument) that the require explicit =
policy=20
  setting is a useless field. &nbsp;A relying party can always set =
acceptable=20
  policies to none. &nbsp;In that scenario, (require explicit policy) =
flag not=20
  withstanding, path validation will succeed. &nbsp;Now, the user can =
examine=20
  the end certificate policy.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">You and I =
have had=20
  this discussion in another context. &nbsp;The basic premise is that =
if some=20
  field in the last certificate only is of interest and the "state" in =
the path=20
  validation process does not impact it, that need not be path of path=20
  validation engine.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thus, you =
can=20
  judiciously use the 3280 Engine and obtain the result you=20
  seek.<o:p></o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  [e-mail] [mailto:[e-mail]] =
<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Guida, Richard=20
  [JJCUS]<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> =
Thursday, June=20
  22, 2006 2:48 PM<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">To:</SPAN></B> Sharon=20
  Boeyen; 'Stefan Santesson'; [e-mail]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> Stephen Kent<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: last call for =
3280bis -=20
  escape clause</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Stefan - =
perhaps I am=20
  missing something, but there is nothing that stops a relying party =
from=20
  writing software that would perform processing extensions&nbsp;only =
on CA=20
  certs as you propose.&nbsp; As <st1:place w:st=3D"on"><st1:City=20
  w:st=3D"on">Sharon</st1:City></st1:place> properly notes, that would =
not be=20
  RFC3280 compliant - but a relying party can choose to be =
non-compliant if it=20
  wishes.&nbsp; And such non-compliance only puts the relying party at =
risk, not=20
  others - so that is&nbsp;a "good thing" relatively speaking.&nbsp; =
But in the=20
  final analysis, seems to me that <st1:place w:st=3D"on"><st1:City=20
  w:st=3D"on">Sharon</st1:City></st1:place> is absolutely correct =
(assuming she=20
  and I are interpreting your proposal properly)&nbsp;- unless X.509 is =

  redefined, this would remain a circumstance of non-compliance.&nbsp; =
And so it=20
  should be treated as&nbsp;such.&nbsp; Very best regards --=20
  Rich</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P><B><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Richard A.=20
  Guida</SPAN></FONT></B> <BR><B><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Director,=20
  Information Security</SPAN></FONT></B> <o:p></o:p></P>
  <P><B><I><FONT face=3D"Times New Roman" color=3Dred size=3D5><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 18pt; COLOR: red; FONT-STYLE: =
italic">Johnson=20
  &amp; Johnson</SPAN></FONT></I></B> <BR><FONT face=3DArial =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Room =
GS8217</SPAN></FONT>=20
  <BR><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">410 <st1:address=20
  w:st=3D"on"><st1:Street w:st=3D"on">George Street</st1:Street><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'">=20
  <BR></SPAN></FONT><st1:City w:st=3D"on">New Brunswick</st1:City>, =
<st1:State=20
  w:st=3D"on">New Jersey</st1:State>&nbsp; <st1:PostalCode=20
  w:st=3D"on">08901</st1:PostalCode></st1:address></SPAN></FONT> =
<BR><FONT=20
  face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Phone:&nbsp; 732 524=20
  3785</SPAN></FONT> <o:p></o:p></P>
  <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; =
MARGIN-RIGHT: 0in">
    <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT =
face=3DTahoma=20
    size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">-----Original=20
    Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">From:</SPAN></B>=20
    [e-mail] =
[mailto:[e-mail]]<B><SPAN=20
    style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Sharon =
Boeyen<BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, June 22, =
2006 1:57=20
    PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> 'Stefan =
Santesson';=20
    [e-mail]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
    Stephen Kent<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B> RE:=20
    last call for 3280bis - escape clause</SPAN></FONT><o:p></o:p></P>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =

    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Stefan, =
if I=20
    understand your comment correctly I strongly believe such an escape =
clause=20
    cannot possibly be added because this would render 3280bis =
non-compliant=20
    with X.509. </SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =

    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">My =
understanding of=20
    your comment is that the escape clause would enable a path =
validation engine=20
    to process the certificate policy OIDs found in CA certificates but =
ignore=20
    those found in EE certificates. Is that a correct understanding?=20
    </SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =

    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">If it is =
a correct=20
    understanding, then any such implementation is non-conformant to =
X.509. 3280=20
    is a profile of X.509 and as such can mandate certain optional =
elements or=20
    exclude optional elements but cannot reverse the mandatory =
processing from=20
    X.509.</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =

    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Apologies if I've=20
    misunderstood your question.</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN =

    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Cheers,</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal><st1:place w:st=3D"on"><st1:City =
w:st=3D"on"><FONT face=3DArial=20
    color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Sharon</SPAN></FONT></st1:City></st1:place><o:p></o:p></P></DIV>
    <BLOCKQUOTE=20
      style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in"><P=20
      class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT =
face=3DTahoma size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original=20
      Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">From:</SPAN></B>=20
      [e-mail] =
[mailto:[e-mail]]=20
      <B><SPAN style=3D"FONT-WEIGHT: bold">On Behalf Of =
</SPAN></B>Stefan=20
      Santesson<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Sent:</SPAN></B>=20
      Wednesday, June 21, 2006 5:23 PM<BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
[e-mail]<BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> Stephen =
Kent<BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: last call for =
3280bis -=20
      escape clause</SPAN></FONT><o:p></o:p></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As a =
last call=20
      comment on RFC 3280bis I would like to raise the question whether =
RFC=20
      3280bis should include an escape clause clearly allowing relying =
parties=20
      to select what validation logic they deploy on certificate=20
      validation.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The =
background is=20
      the fact that many deployed PKIs are=20
      misconfigured.2<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">One =
such common=20
      misconfiguration is assignment of certificate policies and their =
inclusion=20
      in CA certificates.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">X.509 =
path=20
      processing requires policies in CA certificates to reflect the =
list of EE=20
      certificate policies that are valid for a path. Yet many =
deployments have=20
      included pure CA certificate policies in CA certificates, =
policies that=20
      are not included in any EE certificates and as such, policy =
processing is=20
      not possible in such PKIs.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Application=20
      wanting to use certificate policies in such PKI are simply forced =
to=20
      either fail or selectively neglect certain path processing rules. =
For a=20
      relying party such modification could be reasonable if the =
security=20
      implications has been well though =
through.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">However it is not=20
      clear if an implementation allowing such local configuration =
could be=20
      regarded as standard compliant.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">There =
are more=20
      examples where deploying applications in misconfigured PKIs would =
need=20
      similar measures to work.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The =
pki4ipsec WG=20
      recently came to this conclusion in their PKI profile and this =
lead to an=20
      intense debate which included core participants from the PKIX=20
      WG.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The =
result was=20
      that the pki4ipsec profile included an escape clause as=20
      follows:<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">4.1.&nbsp; X.509 =
Certificates<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; Users =
deploying IKE and IPsec with certificates have often had =
little<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; control over the =
capabilities of CAs available to =
them.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; Implementations =
of this specification may include configuration =
knobs<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; to disable checks =
required by this specification in =
orde!<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt"> r =
t<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt"> o =
permit<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; use with =
inflexible and/or noncompliant CAs.&nbsp; However, all checks =
on<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; certificates =
exist for a specific reason involving the security =
of<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; the entire =
system.&nbsp; Therefore, all checks MUST be enabled by =
default.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; Administrators =
and users ought to understand the security purpose =
for<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; the various =
checks, and be clear on what security will be lost =
by<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN e=3D"FONT-SIZE: 10pt" styl!><SPAN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp; disabling the =
check.<o:p></o:p></SPAN></FONT></PRE></SPAN>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I'm =
basically=20
      asking if RFC 3280bis path validation needs a similar escape =
clause or=20
      corresponding clarification that clearly allows local =
configuration of the=20
      validation logic.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">At =
least I think=20
      it is necessary to clearly allow such configuration of standards =
compliant=20
      applications as long as this is not the default=20
      functionality.<o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <DIV>
      <P class=3DMsoNormal><STRONG><B><FONT face=3DArial color=3Dmaroon =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: maroon; FONT-FAMILY: =
Arial">Stefan=20
      Santesson</SPAN></FONT></B></STRONG><FONT color=3Dnavy><SPAN=20
      style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3D#400040 =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: =
Arial">Senior Program=20
      Manager</SPAN></FONT><FONT color=3Dnavy><SPAN=20
      style=3D"COLOR: navy"><o:p></o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><STRONG><B><FONT face=3DArial =
color=3D#400040 size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: #400040; FONT-FAMILY: =
Arial">Windows=20
      Security, =
Standards</SPAN></FONT></B></STRONG><o:p></o:p></P></DIV>
      <DIV>
      <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">
      <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
      </SPAN></FONT></DIV>
      <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
      style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
      face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; =
FONT-FAMILY: Tahoma">=20
      [e-mail] =
[mailto:[e-mail]]=20
      <B><SPAN style=3D"FONT-WEIGHT: bold">On Behalf Of =
</SPAN></B>Stephen=20
      Kent<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> den =
16 juni=20
      2006 22:42<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =

      [e-mail]<BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> last call for=20
      3280bis</SPAN></FONT><o:p></o:p></P></DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt">Folks,<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt">Based on the latest message from David =
Cooper, I=20
      am initiating last call on</SPAN></FONT><FONT size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt"> "Internet X.509 Public Key =
Infrastructure,=20
      Certificate and Certificate Revocation List (CRL)=20
      Profile"</SPAN></FONT><TT><FONT face=3D"Courier New" =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt"> (</SPAN></FONT></TT><A=20
      =
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.tx=
t"><FONT=20
      size=3D2><SPAN=20
      style=3D"FONT-SIZE: =
10pt">http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt<=
/SPAN></FONT></A><FONT=20
      size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">)</SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: =
10pt">&nbsp;</SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt">The last call will last for two weeks. =
In=20
      deference to the U.S. Independence Dya holiday (which means July =
3rd is a=20
      holiday for many folks), all comments must be received by July=20
      5th.</SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: =
10pt">Steve</SPAN></FONT><o:p></o:p></P></DIV></BLOCKQUOTE></BLOCKQUOTE>=
</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C696B5.8CC0B636--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N9sWww039358; Fri, 23 Jun 2006 02:54:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N9sWSq039357; Fri, 23 Jun 2006 02:54:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N9sUv1039334 for <[e-mail]>; Fri, 23 Jun 2006 02:54:31 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 10:54:27 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples
Date: Fri, 23 Jun 2006 10:54:26 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples
thread-index: AcaWWVJxh0AAs+BBSLGoi/jkDBS2aQAEuBXgAA8httA=
From: "Stefan Santesson" <[e-mail]>
To: "Manger, James H" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 23 Jun 2006 09:54:27.0346 (UTC) FILETIME=[03C51720:01C696AB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k5N9sVv1039352
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 the review James,

Comments in-line,

Stefan Santesson
Senior Program Manager
Windows Security, Standards


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Manger, James H
Sent: den 23 juni 2006 06:50
To: [e-mail]
Subject: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples


Comments on draft-ietf-pkix-srvsan-02.txt


1. Abstract, page 1, typo:
  "filed" -> "field"

<Stefan> Will be fixed

2. It would be nice if the full value of the id-on-dnsSRV object
identifier was provided in this document, without requiring a separate
lookup of RFC 3280. Add the following ASN.1 comment just above the id-on
definition in Appendix A.1 (page 8), Appendix A.2 (page 8) and section 2
"Name Definitions" (page 3):
  -- id-pkix OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7}

<Stefan> OK

3. Include an example with an IDN so it is immediately obvious that
punycode is not used in an SRVName value.  Add the following after the
current example in section 2, page 4:

  Example:
  The "mail" service at na<LATIN SMALL LETTER I WITH DIAERESIS>ve.net
  (an IDN, which becomes xn--nave-6pa.net when encoded as an IDNA)
  would use the following 15-character SRVName value:
    _mail.na<LATIN SMALL LETTER I WITH DIAERESIS>ve.net
  Its 16-byte UTF-8 encoding is (in hex):
    5F 6D 61 69 6C 2E 6E 61 C3 AF 76 65 2E 6E 65 74


<Stefan> Thanks for providing the sample. Looks fine to me.

4. Appendix A.2 (page 9), glitch:
  "permanentIdentifier" -> "srvName"

<Stefan> OK I'm caught. Yes I borrowed some constructions from the PI
draft. Thought I got that fixed.

5. Why bother with the (SIZE (1..MAX)) restriction?  Delete it.

<Stefan> It seems to be the custom to use it. I don't feel enough of an
ASN.1 expert to have the correct answer. Someone else may have an
opinon. I'll be happy to remove it as long as it works.

6. SRVName is defined (in section 2) to have the form _Service.Name.
The very next section violates that definition by allowing SRVName to
hold just a service name or just a domain name.  The syntax to hold a
name is not necessarily the same syntax required to hold a matching rule
for that name.  This is a general fault with the construction of the
nameConstraints extension so it does not need to be fixed in this
specification (I am just having a rant).

<Stefan> Yes, as you state yourself. The actual name in SAN and matching
data in name constraints have different syntax rules. Simply to avoid
definition of wildcards. I think its fin as it is.

7. Appendix A, page 7:
  "augmented with 1993 the UNIVERSAL Type" ->
  "augmented with the 1993 UNIVERSAL Type"

<Stefan> OK

8. Appendix A.  Are the modules names supposed to end with "..SAN88" and
"..SAN93", or is it supposed to be "..ASN88" and "..ASN93"?

<Stefan> The current names are the names assigned by Russ,

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Friday, 23 June 2006 8:50 AM
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-srvsan-02.txt 

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
Subject Alternative Name for expression of service name
	Author(s)	: S. Santesson
	Filename	: draft-ietf-pkix-srvsan-02.txt
	Pages		: 11
	Date		: 2006-6-22
	
This document defines a new name form for inclusion in the otherName
filed of an X.509 Subject Alternative Name extension which allows a
certificate subject to be associated with the service name and domain
name components of a DNS Service Resource Record.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of
the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N9SV1o033764; Fri, 23 Jun 2006 02:28:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N9SVIA033763; Fri, 23 Jun 2006 02:28:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N9STHA033741 for <[e-mail]>; Fri, 23 Jun 2006 02:28:29 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 10:28:23 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696A7.5F1E4C4B"
Subject: RE: last call for 3280bis - escape clause
Date: Fri, 23 Jun 2006 10:28:21 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: last call for 3280bis - escape clause
thread-index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsAAAeBmuAAAJmXEAAN+MPw
From: "Stefan Santesson" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 23 Jun 2006 09:28:23.0153 (UTC) FILETIME=[5F702E10:01C696A7]
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_001_01C696A7.5F1E4C4B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Santosh,

=20

Yes, you are correct that the path will validate without any error in
your example.=20

It will also have an empty set of valid policies. So accepting the EE
certificate policies as valid (using that path) do require some kind of
non-conformant policy checking.

=20

I agree on your conclusion. However I have experienced implementers not
feeling sure about this principle. Especially when it comes to
configuration options enabled by an administrative UI and not just some
mode switch in the OS.

The escape clause in pki4ipsic was driven by this uncertainty.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: Santosh Chokhani [mailto:[e-mail]]=20
Sent: den 23 juni 2006 02:48
To: Stefan Santesson; [e-mail]
Subject: RE: last call for 3280bis - escape clause

=20

Stefan,

=20

On disagree with you on 2.  You seem to be asking for 2 and then saying
that it is not valid.

=20

A path validation profile (assuming we agree to ignore "require explicit
policy") with setting acceptable policy set to anyPolicy is valid X.509
and 3280 configuration.  In that case, there will not be a policy
failure and relying party can always make additional checks.  I
encourage you to look at Section J.3 in Annex J of X.509.  If you see
any errors in Annex J, please let me know.

=20

As to Standard compliant implementation putting itself in non-compliant
mode, that is always acceptable.  In that mode it will NOT be standard
compliant; that is all.

________________________________

From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Thursday, June 22, 2006 8:39 PM
To: Santosh Chokhani; [e-mail]
Subject: RE: last call for 3280bis - escape clause

=20

Santosh,

=20

There are 2 distinct reasons why your approach is not a generic solution
to the problem.

=20

1)       The problem is generic and does not only apply to policy
processing. The pki4ipsec issue was e.g. motivated from problems with
EKU settings in existing certificates that does not satisfy new
applications and usages.

2)       If you need to test for a policy in the end certificate, that
policy will not be valid unless supported by the path, regardless if
policy constraints was set or not.

=20

In the perfect world, compliant path processing will always do the job.
In the real world, you may need to tweak the rules to make a new
application fit into an existing infrastructure-

=20

The question is still: Can a standards compliant implementation allow
configuration of non conformant modifications to the validation process,
or does that make the implementation as a whole non-conformant.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 22:59
To: [e-mail]
Subject: RE: last call for 3280bis - escape clause

=20

Stefan,

=20

I agree with sentiments voiced by Steve, Rich, and Sharon.

=20

I have a simple solution to your concern from the relying party
viewpoint.  This observation is made with a long-held view of mine (and
no one had provided a convincing logical or business argument) that the
require explicit policy setting is a useless field.  A relying party can
always set acceptable policies to none.  In that scenario, (require
explicit policy) flag not withstanding, path validation will succeed.
Now, the user can examine the end certificate policy.

=20

You and I have had this discussion in another context.  The basic
premise is that if some field in the last certificate only is of
interest and the "state" in the path validation process does not impact
it, that need not be path of path validation engine.

=20

Thus, you can judiciously use the 3280 Engine and obtain the result you
seek.

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Guida, Richard [JJCUS]
Sent: Thursday, June 22, 2006 2:48 PM
To: Sharon Boeyen; 'Stefan Santesson'; [e-mail]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

=20

Stefan - perhaps I am missing something, but there is nothing that stops
a relying party from writing software that would perform processing
extensions only on CA certs as you propose.  As Sharon properly notes,
that would not be RFC3280 compliant - but a relying party can choose to
be non-compliant if it wishes.  And such non-compliance only puts the
relying party at risk, not others - so that is a "good thing" relatively
speaking.  But in the final analysis, seems to me that Sharon is
absolutely correct (assuming she and I are interpreting your proposal
properly) - unless X.509 is redefined, this would remain a circumstance
of non-compliance.  And so it should be treated as such.  Very best
regards -- Rich

=20

=20

=20

Richard A. Guida=20
Director, Information Security=20

Johnson & Johnson=20
Room GS8217=20
410 George Street=20
New Brunswick, New Jersey  08901=20
Phone:  [phone]=20

	-----Original Message-----
	From: [e-mail]
[mailto:[e-mail]]On Behalf Of Sharon Boeyen
	Sent: Thursday, June 22, 2006 1:57 PM
	To: 'Stefan Santesson'; [e-mail]
	Cc: Stephen Kent
	Subject: RE: last call for 3280bis - escape clause

	Stefan, if I understand your comment correctly I strongly
believe such an escape clause cannot possibly be added because this
would render 3280bis non-compliant with X.509.=20

	=20

	My understanding of your comment is that the escape clause would
enable a path validation engine to process the certificate policy OIDs
found in CA certificates but ignore those found in EE certificates. Is
that a correct understanding?=20

	=20

	If it is a correct understanding, then any such implementation
is non-conformant to X.509. 3280 is a profile of X.509 and as such can
mandate certain optional elements or exclude optional elements but
cannot reverse the mandatory processing from X.509.

	=20

	Apologies if I've misunderstood your question.

	=20

	Cheers,

	Sharon

		-----Original Message-----
		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
		Sent: Wednesday, June 21, 2006 5:23 PM
		To: [e-mail]
		Cc: Stephen Kent
		Subject: RE: last call for 3280bis - escape clause

		As a last call comment on RFC 3280bis I would like to
raise the question whether RFC 3280bis should include an escape clause
clearly allowing relying parties to select what validation logic they
deploy on certificate validation.

		=20

		The background is the fact that many deployed PKIs are
misconfigured.2

		One such common misconfiguration is assignment of
certificate policies and their inclusion in CA certificates.

		X.509 path processing requires policies in CA
certificates to reflect the list of EE certificate policies that are
valid for a path. Yet many deployments have included pure CA certificate
policies in CA certificates, policies that are not included in any EE
certificates and as such, policy processing is not possible in such
PKIs.

		=20

		Application wanting to use certificate policies in such
PKI are simply forced to either fail or selectively neglect certain path
processing rules. For a relying party such modification could be
reasonable if the security implications has been well though through.

		However it is not clear if an implementation allowing
such local configuration could be regarded as standard compliant.

		=20

		There are more examples where deploying applications in
misconfigured PKIs would need similar measures to work.

		=20

		The pki4ipsec WG recently came to this conclusion in
their PKI profile and this lead to an intense debate which included core
participants from the PKIX WG.

		=20

		The result was that the pki4ipsec profile included an
escape clause as follows:

		=20

		4.1.  X.509 Certificates
		=20
		   Users deploying IKE and IPsec with certificates have
often had little
		   control over the capabilities of CAs available to
them.
		   Implementations of this specification may include
configuration knobs
		   to disable checks required by this specification in
orde!
		 r t
		 o permit
		   use with inflexible and/or noncompliant CAs.
However, all checks on
		   certificates exist for a specific reason involving
the security of
		   the entire system.  Therefore, all checks MUST be
enabled by default.
		   Administrators and users ought to understand the
security purpose for
		   the various checks, and be clear on what security
will be lost by
		   disabling the check.

		=20

		=20

		I'm basically asking if RFC 3280bis path validation
needs a similar escape clause or corresponding clarification that
clearly allows local configuration of the validation logic.

		At least I think it is necessary to clearly allow such
configuration of standards compliant applications as long as this is not
the default functionality.

		=20

		=20

		Stefan Santesson

		Senior Program Manager

		Windows Security, Standards

	=09
________________________________


		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stephen Kent
		Sent: den 16 juni 2006 22:42
		To: [e-mail]
		Subject: last call for 3280bis

		=20

		Folks,

		=20

		Based on the latest message from David Cooper, I am
initiating last call on "Internet X.509 Public Key Infrastructure,
Certificate and Certificate Revocation List (CRL) Profile"
(http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt> )

		=20

		The last call will last for two weeks. In deference to
the U.S. Independence Dya holiday (which means July 3rd is a holiday for
many folks), all comments must be received by July 5th.

		=20

		Steve


------_=_NextPart_001_01C696A7.5F1E4C4B
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:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Message</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
tt
	{font-family:"Courier New";}
p.stylecentered, li.stylecentered, div.stylecentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.stylecentered0, li.stylecentered0, div.stylecentered0
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle25
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle27
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:361246706;
	mso-list-type:hybrid;
	mso-list-template-ids:9974032 67698705 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Yes, you are correct that the path =
will validate
without any error in your example. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>It will also have an empty set of =
valid
policies. So accepting the EE certificate policies as valid (using that =
path) do
require some kind of non-conformant policy =
checking.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree on your conclusion. However =
I have
experienced implementers not feeling sure about this principle. =
Especially when
it comes to configuration options enabled by an administrative UI and =
not just
some mode switch in the OS.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The escape clause in pki4ipsic was =
driven
by this uncertainty.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Santosh Chokhani
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 23 juni 2006 =
02:48<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Stefan Santesson;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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


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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>On disagree with you on 2. =
&nbsp;You seem
to be asking for 2 and then saying that it is not =
valid.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>A path validation profile (assuming =
we
agree to ignore &#8220;require explicit policy&#8221;) with setting =
acceptable
policy set to anyPolicy is valid X.509 and 3280 configuration. &nbsp;In =
that
case, there will not be a policy failure and relying party can always =
make
additional checks. &nbsp;I encourage you to look at Section J.3 in Annex =
J of
X.509. &nbsp;If you see any errors in Annex J, please let me =
know.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As to Standard compliant =
implementation
putting itself in non-compliant mode, that is always acceptable. =
&nbsp;In that
mode it will NOT be standard compliant; that is =
all.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Stefan Santesson
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 8:39
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Santosh Chokhani;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are 2 distinct reasons why =
your
approach is not a generic solution to the =
problem.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 =
lfo4'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>1)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>The problem is generic and does not only apply to policy
processing. The pki4ipsec issue was e.g. motivated from problems with =
EKU
settings in existing certificates that does not satisfy new applications =
and
usages.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 =
lfo4'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>2)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>If you need to test for a policy in the end certificate, =
that
policy will not be valid unless supported by the path, regardless if =
policy
constraints was set or not.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In the perfect world, compliant =
path
processing will always do the job. In the real world, you may need to =
tweak the
rules to make a new application fit into an existing =
infrastructure-<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The question is still: Can a =
standards
compliant implementation allow configuration of non conformant =
modifications to
the validation process, or does that make the implementation as a whole
non-conformant.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Santosh Chokhani<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 22 juni 2006 =
22:59<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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


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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree with sentiments voiced by =
Steve,
Rich, and Sharon.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I have a simple solution to your =
concern
from the relying party viewpoint.&nbsp; This observation is made with a
long-held view of mine (and no one had provided a convincing logical or
business argument) that the require explicit policy setting is a useless =
field.
&nbsp;A relying party can always set acceptable policies to none. =
&nbsp;In that
scenario, (require explicit policy) flag not withstanding, path =
validation will
succeed. &nbsp;Now, the user can examine the end certificate =
policy.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>You and I have had this discussion =
in
another context. &nbsp;The basic premise is that if some field in the =
last
certificate only is of interest and the &#8220;state&#8221; in the path
validation process does not impact it, that need not be path of path =
validation
engine.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thus, you can judiciously use the =
3280
Engine and obtain the result you seek.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Guida, Richard =
[JJCUS]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 2:48
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sharon Boeyen; =
'Stefan
Santesson'; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan - perhaps I am missing =
something,
but there is nothing that stops a relying party from writing software =
that
would perform processing extensions&nbsp;only on CA certs as you =
propose.&nbsp;
As <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Sharon</st1:City></st1:place>
properly notes, that would not be RFC3280 compliant - but a relying =
party can
choose to be non-compliant if it wishes.&nbsp; And such non-compliance =
only
puts the relying party at risk, not others - so that is&nbsp;a =
&quot;good
thing&quot; relatively speaking.&nbsp; But in the final analysis, seems =
to me
that <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Sharon</st1:City></st1:place> is
absolutely correct (assuming she and I are interpreting your proposal
properly)&nbsp;- unless X.509 is redefined, this would remain a =
circumstance of
non-compliance.&nbsp; And so it should be treated as&nbsp;such.&nbsp; =
Very best
regards -- Rich</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Richard A. Guida</span></font></b> <br>
<b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Director, Information Security</span></font></b> =
<o:p></o:p></p>

<p><b><i><font size=3D5 color=3Dred face=3D"Times New Roman"><span =
style=3D'font-size:
18.0pt;color:red;font-weight:bold;font-style:italic'>Johnson &amp; =
Johnson</span></font></i></b>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Room
GS8217</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>410 <st1:address
w:st=3D"on"><st1:Street w:st=3D"on">George Street</st1:Street><font =
size=3D3
 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;font-family:"Times New Roman"'>
 <br>
 </span></font><st1:City w:st=3D"on">New Brunswick</st1:City>, =
<st1:State w:st=3D"on">New
  Jersey</st1:State>&nbsp; <st1:PostalCode =
w:st=3D"on">08901</st1:PostalCode></st1:address></span></font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Phone:&nbsp;
732 524 3785</span></font> <o:p></o:p></p>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]]<b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Sharon Boeyen<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 1:57
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Stefan Santesson';
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan, if I understand your =
comment
correctly I strongly believe such an escape clause cannot possibly be =
added
because this would render 3280bis non-compliant with X.509. =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>My understanding of your comment is =
that
the escape clause would enable a path validation engine to process the
certificate policy OIDs found in CA certificates but ignore those found =
in EE
certificates. Is that a correct understanding? =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If it is a correct understanding, =
then any
such implementation is non-conformant to X.509. 3280 is a profile of =
X.509 and
as such can mandate certain optional elements or exclude optional =
elements but
cannot reverse the mandatory processing from =
X.509.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Apologies if I've misunderstood =
your
question.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

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


</div>

<div>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2
  color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:blue'>Sharon</span></font></st1:City></st1:place><o:p></o:p></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, June 21, =
2006
5:23 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As a last call comment on RFC =
3280bis I
would like to raise the question whether RFC 3280bis should include an =
escape
clause clearly allowing relying parties to select what validation logic =
they
deploy on certificate validation.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The background is the fact that =
many
deployed PKIs are misconfigured.2<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>One such common misconfiguration is
assignment of certificate policies and their inclusion in CA =
certificates.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>X.509 path processing requires =
policies in
CA certificates to reflect the list of EE certificate policies that are =
valid
for a path. Yet many deployments have included pure CA certificate =
policies in
CA certificates, policies that are not included in any EE certificates =
and as
such, policy processing is not possible in such =
PKIs.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Application wanting to use =
certificate
policies in such PKI are simply forced to either fail or selectively =
neglect
certain path processing rules. For a relying party such modification =
could be
reasonable if the security implications has been well though =
through.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>However it is not clear if an
implementation allowing such local configuration could be regarded as =
standard
compliant.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are more examples where =
deploying
applications in misconfigured PKIs would need similar measures to =
work.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The pki4ipsec WG recently came to =
this
conclusion in their PKI profile and this lead to an intense debate which
included core participants from the PKIX =
WG.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The result was that the pki4ipsec =
profile
included an escape clause as follows:<o:p></o:p></span></font></p>

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

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>4.1.&nbsp; X.509 =
Certificates<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Users deploying IKE and IPsec =
with certificates have often had =
little<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; control over the capabilities of =
CAs available to them.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Implementations of this =
specification may include configuration =
knobs<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; to disable checks required by =
this specification in orde!<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> r =
t<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> o =
permit<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; use with inflexible and/or =
noncompliant CAs.&nbsp; However, all checks =
on<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; certificates exist for a =
specific reason involving the security =
of<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the entire system.&nbsp; =
Therefore, all checks MUST be enabled by =
default.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Administrators and users ought =
to understand the security purpose =
for<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the various checks, and be clear =
on what security will be lost =
by<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span styl! e=3D"FONT-SIZE: 10pt"><span
style=3D'font-size:10.0pt'>&nbsp;&nbsp; disabling the =
check.<o:p></o:p></span></font></pre></span>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I'm basically asking if RFC 3280bis =
path
validation needs a similar escape clause or corresponding clarification =
that
clearly allows local configuration of the validation =
logic.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>At least I think it is necessary to
clearly allow such configuration of standards compliant applications as =
long as
this is not the default functionality.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 16 juni 2006 =
22:42<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> last call for =
3280bis</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Folks,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Based on the latest message from David Cooper, I am initiating =
last
call on</span></font><font size=3D2><span style=3D'font-size:10.0pt'>
&quot;Internet X.509 Public Key Infrastructure, Certificate and =
Certificate
Revocation List (CRL) Profile&quot;</span></font><tt><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt'> =
(</span></font></tt><a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt=
"><font
size=3D2><span =
style=3D'font-size:10.0pt'>http://ietf.org/internet-drafts/draft-ietf-pki=
x-rfc3280bis-03.txt</span></font></a><font
size=3D2><span style=3D'font-size:10.0pt'>)</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>The last call will last for two weeks. In deference to the U.S.
Independence Dya holiday (which means July 3rd is a holiday for many =
folks),
all comments must be received by July 5th.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Steve</span></font><o:p></o:p></p>

</div>

</blockquote>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C696A7.5F1E4C4B--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N4o15Q071649; Thu, 22 Jun 2006 21:50:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N4o1dm071648; Thu, 22 Jun 2006 21:50:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N4nwH9071620 for <[e-mail]>; Thu, 22 Jun 2006 21:49:59 -0700 (MST) (envelope-from [e-mail])
Received: from webi.ntcif.telstra.com.au (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbo.ntcif.telstra.com.au with ESMTP; 23 Jun 2006 14:49:57 +1000
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 2A2B5FF82 for <[e-mail]>; Fri, 23 Jun 2006 14:49:57 +1000 (EST)
Received: from wsmsg2902.srv.dir.telstra.com (wsmsg2902.srv.dir.telstra.com [172.49.40.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA25844 for <[e-mail]>; Fri, 23 Jun 2006 14:49:56 +1000 (EST)
Received: from WSMSG2103V.srv.dir.telstra.com ([172.49.40.20]) by wsmsg2902.srv.dir.telstra.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 14:49:52 +1000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Subject: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples
Date: Fri, 23 Jun 2006 14:49:51 +1000
Message-ID: <[e-mail]>
Thread-Topic: SRV Name: draft-ietf-pkix-srvsan-02.txt: typos, examples
Thread-Index: AcaWWVJxh0AAs+BBSLGoi/jkDBS2aQAEuBXg
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 23 Jun 2006 04:49:52.0590 (UTC) FILETIME=[772A9EE0:01C69680]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by balder-227.proper.com id k5N4o0H9071633
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 on draft-ietf-pkix-srvsan-02.txt


1. Abstract, page 1, typo:
  "filed" -> "field"


2. It would be nice if the full value of the id-on-dnsSRV object identifier was provided in this document, without requiring a separate lookup of RFC 3280. Add the following ASN.1 comment just above the id-on definition in Appendix A.1 (page 8), Appendix A.2 (page 8) and section 2 "Name Definitions" (page 3):
  -- id-pkix OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7}


3. Include an example with an IDN so it is immediately obvious that punycode is not used in an SRVName value.  Add the following after the current example in section 2, page 4:

  Example:
  The "mail" service at na<LATIN SMALL LETTER I WITH DIAERESIS>ve.net
  (an IDN, which becomes xn--nave-6pa.net when encoded as an IDNA)
  would use the following 15-character SRVName value:
    _mail.na<LATIN SMALL LETTER I WITH DIAERESIS>ve.net
  Its 16-byte UTF-8 encoding is (in hex):
    5F 6D 61 69 6C 2E 6E 61 C3 AF 76 65 2E 6E 65 74


4. Appendix A.2 (page 9), glitch:
  "permanentIdentifier" -> "srvName"


5. Why bother with the (SIZE (1..MAX)) restriction?  Delete it.


6. SRVName is defined (in section 2) to have the form _Service.Name.  The very next section violates that definition by allowing SRVName to hold just a service name or just a domain name.  The syntax to hold a name is not necessarily the same syntax required to hold a matching rule for that name.  This is a general fault with the construction of the nameConstraints extension so it does not need to be fixed in this specification (I am just having a rant).


7. Appendix A, page 7:
  "augmented with 1993 the UNIVERSAL Type" ->
  "augmented with the 1993 UNIVERSAL Type"


8. Appendix A.  Are the modules names supposed to end with "..SAN88" and "..SAN93", or is it supposed to be "..ASN88" and "..ASN93"?


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Friday, 23 June 2006 8:50 AM
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-srvsan-02.txt 

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 Subject Alternative Name for expression of service name
	Author(s)	: S. Santesson
	Filename	: draft-ietf-pkix-srvsan-02.txt
	Pages		: 11
	Date		: 2006-6-22
	
This document defines a new name form for inclusion in the otherName
filed of an X.509 Subject Alternative Name extension which allows a
certificate subject to be associated with the service name and domain
name components of a DNS Service Resource Record.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N0lfAd007868; Thu, 22 Jun 2006 17:47:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N0lfct007867; Thu, 22 Jun 2006 17:47:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N0leg9007832 for <[e-mail]>; Thu, 22 Jun 2006 17:47:41 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6965F.1CC1663D"
Subject: RE: last call for 3280bis - escape clause
Date: Thu, 22 Jun 2006 17:47:35 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: last call for 3280bis - escape clause
Thread-Index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsAAAeBmuAAAJmXEA==
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[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>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6965F.1CC1663D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

On disagree with you on 2.  You seem to be asking for 2 and then saying
that it is not valid.

=20

A path validation profile (assuming we agree to ignore "require explicit
policy") with setting acceptable policy set to anyPolicy is valid X.509
and 3280 configuration.  In that case, there will not be a policy
failure and relying party can always make additional checks.  I
encourage you to look at Section J.3 in Annex J of X.509.  If you see
any errors in Annex J, please let me know.

=20

As to Standard compliant implementation putting itself in non-compliant
mode, that is always acceptable.  In that mode it will NOT be standard
compliant; that is all.

________________________________

From: Stefan Santesson [mailto:[e-mail]]=20
Sent: Thursday, June 22, 2006 8:39 PM
To: Santosh Chokhani; [e-mail]
Subject: RE: last call for 3280bis - escape clause

=20

Santosh,

=20

There are 2 distinct reasons why your approach is not a generic solution
to the problem.

=20

1)       The problem is generic and does not only apply to policy
processing. The pki4ipsec issue was e.g. motivated from problems with
EKU settings in existing certificates that does not satisfy new
applications and usages.

2)       If you need to test for a policy in the end certificate, that
policy will not be valid unless supported by the path, regardless if
policy constraints was set or not.

=20

In the perfect world, compliant path processing will always do the job.
In the real world, you may need to tweak the rules to make a new
application fit into an existing infrastructure-

=20

The question is still: Can a standards compliant implementation allow
configuration of non conformant modifications to the validation process,
or does that make the implementation as a whole non-conformant.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 22:59
To: [e-mail]
Subject: RE: last call for 3280bis - escape clause

=20

Stefan,

=20

I agree with sentiments voiced by Steve, Rich, and Sharon.

=20

I have a simple solution to your concern from the relying party
viewpoint.  This observation is made with a long-held view of mine (and
no one had provided a convincing logical or business argument) that the
require explicit policy setting is a useless field.  A relying party can
always set acceptable policies to none.  In that scenario, (require
explicit policy) flag not withstanding, path validation will succeed.
Now, the user can examine the end certificate policy.

=20

You and I have had this discussion in another context.  The basic
premise is that if some field in the last certificate only is of
interest and the "state" in the path validation process does not impact
it, that need not be path of path validation engine.

=20

Thus, you can judiciously use the 3280 Engine and obtain the result you
seek.

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Guida, Richard [JJCUS]
Sent: Thursday, June 22, 2006 2:48 PM
To: Sharon Boeyen; 'Stefan Santesson'; [e-mail]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

=20

Stefan - perhaps I am missing something, but there is nothing that stops
a relying party from writing software that would perform processing
extensions only on CA certs as you propose.  As Sharon properly notes,
that would not be RFC3280 compliant - but a relying party can choose to
be non-compliant if it wishes.  And such non-compliance only puts the
relying party at risk, not others - so that is a "good thing" relatively
speaking.  But in the final analysis, seems to me that Sharon is
absolutely correct (assuming she and I are interpreting your proposal
properly) - unless X.509 is redefined, this would remain a circumstance
of non-compliance.  And so it should be treated as such.  Very best
regards -- Rich

=20

=20

=20

Richard A. Guida=20
Director, Information Security=20

Johnson & Johnson=20
Room GS8217=20
410 George Street=20
New Brunswick, New Jersey  08901=20
Phone:  [phone]=20

	-----Original Message-----
	From: [e-mail]
[mailto:[e-mail]]On Behalf Of Sharon Boeyen
	Sent: Thursday, June 22, 2006 1:57 PM
	To: 'Stefan Santesson'; [e-mail]
	Cc: Stephen Kent
	Subject: RE: last call for 3280bis - escape clause

	Stefan, if I understand your comment correctly I strongly
believe such an escape clause cannot possibly be added because this
would render 3280bis non-compliant with X.509.=20

	=20

	My understanding of your comment is that the escape clause would
enable a path validation engine to process the certificate policy OIDs
found in CA certificates but ignore those found in EE certificates. Is
that a correct understanding?=20

	=20

	If it is a correct understanding, then any such implementation
is non-conformant to X.509. 3280 is a profile of X.509 and as such can
mandate certain optional elements or exclude optional elements but
cannot reverse the mandatory processing from X.509.

	=20

	Apologies if I've misunderstood your question.

	=20

	Cheers,

	Sharon

		-----Original Message-----
		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
		Sent: Wednesday, June 21, 2006 5:23 PM
		To: [e-mail]
		Cc: Stephen Kent
		Subject: RE: last call for 3280bis - escape clause

		As a last call comment on RFC 3280bis I would like to
raise the question whether RFC 3280bis should include an escape clause
clearly allowing relying parties to select what validation logic they
deploy on certificate validation.

		=20

		The background is the fact that many deployed PKIs are
misconfigured.2

		One such common misconfiguration is assignment of
certificate policies and their inclusion in CA certificates.

		X.509 path processing requires policies in CA
certificates to reflect the list of EE certificate policies that are
valid for a path. Yet many deployments have included pure CA certificate
policies in CA certificates, policies that are not included in any EE
certificates and as such, policy processing is not possible in such
PKIs.

		=20

		Application wanting to use certificate policies in such
PKI are simply forced to either fail or selectively neglect certain path
processing rules. For a relying party such modification could be
reasonable if the security implications has been well though through.

		However it is not clear if an implementation allowing
such local configuration could be regarded as standard compliant.

		=20

		There are more examples where deploying applications in
misconfigured PKIs would need similar measures to work.

		=20

		The pki4ipsec WG recently came to this conclusion in
their PKI profile and this lead to an intense debate which included core
participants from the PKIX WG.

		=20

		The result was that the pki4ipsec profile included an
escape clause as follows:

		=20

		4.1.  X.509 Certificates
		=20
		   Users deploying IKE and IPsec with certificates have
often had little
		   control over the capabilities of CAs available to
them.
		   Implementations of this specification may include
configuration knobs
		   to disable checks required by this specification in
orde!
		 r t
		 o permit
		   use with inflexible and/or noncompliant CAs.
However, all checks on
		   certificates exist for a specific reason involving
the security of
		   the entire system.  Therefore, all checks MUST be
enabled by default.
		   Administrators and users ought to understand the
security purpose for
		   the various checks, and be clear on what security
will be lost by
		   disabling the check.

		=20

		=20

		I'm basically asking if RFC 3280bis path validation
needs a similar escape clause or corresponding clarification that
clearly allows local configuration of the validation logic.

		At least I think it is necessary to clearly allow such
configuration of standards compliant applications as long as this is not
the default functionality.

		=20

		=20

		Stefan Santesson

		Senior Program Manager

		Windows Security, Standards

	=09
________________________________


		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stephen Kent
		Sent: den 16 juni 2006 22:42
		To: [e-mail]
		Subject: last call for 3280bis

		=20

		Folks,

		=20

		Based on the latest message from David Cooper, I am
initiating last call on "Internet X.509 Public Key Infrastructure,
Certificate and Certificate Revocation List (CRL) Profile"
(http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt> )

		=20

		The last call will last for two weeks. In deference to
the U.S. Independence Dya holiday (which means July 3rd is a holiday for
many folks), all comments must be received by July 5th.

		=20

		Steve


------_=_NextPart_001_01C6965F.1CC1663D
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:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Message</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo4;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo4;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
tt
	{font-family:"Courier New";}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.stylecentered0, li.stylecentered0, div.stylecentered0
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle26
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:361246706;
	mso-list-type:hybrid;
	mso-list-template-ids:9974032 67698705 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l2:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l2:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l2:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l2:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l2:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l2:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l2:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l2:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l2:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

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


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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>On disagree with you on 2. =
&nbsp;You seem to be
asking for 2 and then saying that it is not =
valid.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>A path validation profile (assuming =
we
agree to ignore &#8220;require explicit policy&#8221;) with setting =
acceptable
policy set to anyPolicy is valid X.509 and 3280 configuration. &nbsp;In =
that case,
there will not be a policy failure and relying party can always make =
additional
checks. &nbsp;I encourage you to look at Section J.3 in Annex J of =
X.509. &nbsp;If you
see any errors in Annex J, please let me =
know.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As to Standard compliant =
implementation
putting itself in non-compliant mode, that is always acceptable. =
&nbsp;In that mode
it will NOT be standard compliant; that is =
all.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Stefan Santesson
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 8:39
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Santosh Chokhani;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are 2 distinct reasons why =
your
approach is not a generic solution to the =
problem.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 =
lfo6'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>1)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>The problem is generic and does not only apply to policy
processing. The pki4ipsec issue was e.g. motivated from problems with =
EKU
settings in existing certificates that does not satisfy new applications =
and
usages.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 =
lfo6'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>2)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>If you need to test for a policy in the end certificate, =
that
policy will not be valid unless supported by the path, regardless if =
policy
constraints was set or not.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In the perfect world, compliant =
path
processing will always do the job. In the real world, you may need to =
tweak the
rules to make a new application fit into an existing =
infrastructure-<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The question is still: Can a =
standards
compliant implementation allow configuration of non conformant =
modifications to
the validation process, or does that make the implementation as a whole
non-conformant.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Santosh Chokhani<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 22 juni 2006 =
22:59<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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


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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree with sentiments voiced by =
Steve,
Rich, and Sharon.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I have a simple solution to your =
concern
from the relying party viewpoint.&nbsp; This observation is made with a
long-held view of mine (and no one had provided a convincing logical or =
business
argument) that the require explicit policy setting is a useless field. =
&nbsp;A
relying party can always set acceptable policies to none. &nbsp;In that
scenario, (require explicit policy) flag not withstanding, path =
validation will
succeed. &nbsp;Now, the user can examine the end certificate =
policy.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>You and I have had this discussion =
in
another context. &nbsp;The basic premise is that if some field in the =
last
certificate only is of interest and the &#8220;state&#8221; in the path
validation process does not impact it, that need not be path of path =
validation
engine.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thus, you can judiciously use the =
3280
Engine and obtain the result you seek.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Guida, Richard =
[JJCUS]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 2:48
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sharon Boeyen; =
'Stefan
Santesson'; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan - perhaps I am missing =
something,
but there is nothing that stops a relying party from writing software =
that would
perform processing extensions&nbsp;only on CA certs as you =
propose.&nbsp; As <st1:place
w:st=3D"on"><st1:City w:st=3D"on">Sharon</st1:City></st1:place> properly =
notes,
that would not be RFC3280 compliant - but a relying party can choose to =
be
non-compliant if it wishes.&nbsp; And such non-compliance only puts the =
relying
party at risk, not others - so that is&nbsp;a &quot;good thing&quot; =
relatively
speaking.&nbsp; But in the final analysis, seems to me that <st1:place =
w:st=3D"on"><st1:City
 w:st=3D"on">Sharon</st1:City></st1:place> is absolutely correct =
(assuming she
and I are interpreting your proposal properly)&nbsp;- unless X.509 is
redefined, this would remain a circumstance of non-compliance.&nbsp; And =
so it
should be treated as&nbsp;such.&nbsp; Very best regards -- =
Rich</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Richard A. Guida</span></font></b> <br>
<b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Director, Information Security</span></font></b> =
<o:p></o:p></p>

<p><b><i><font size=3D5 color=3Dred face=3D"Times New Roman"><span =
style=3D'font-size:
18.0pt;color:red;font-weight:bold;font-style:italic'>Johnson &amp; =
Johnson</span></font></i></b>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Room
GS8217</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>410 <st1:address
w:st=3D"on"><st1:Street w:st=3D"on">George Street</st1:Street><font =
size=3D3
 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;font-family:"Times New Roman"'>
 <br>
 </span></font><st1:City w:st=3D"on">New Brunswick</st1:City>, =
<st1:State w:st=3D"on">New
  Jersey</st1:State>&nbsp; <st1:PostalCode =
w:st=3D"on">08901</st1:PostalCode></st1:address></span></font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Phone:&nbsp;
732 524 3785</span></font> <o:p></o:p></p>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]]<b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Sharon Boeyen<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 1:57
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Stefan Santesson';
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan, if I understand your =
comment
correctly I strongly believe such an escape clause cannot possibly be =
added
because this would render 3280bis non-compliant with X.509. =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>My understanding of your comment is =
that
the escape clause would enable a path validation engine to process the
certificate policy OIDs found in CA certificates but ignore those found =
in EE
certificates. Is that a correct understanding? =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If it is a correct understanding, =
then any
such implementation is non-conformant to X.509. 3280 is a profile of =
X.509 and
as such can mandate certain optional elements or exclude optional =
elements but
cannot reverse the mandatory processing from =
X.509.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Apologies if I've misunderstood =
your
question.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

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


</div>

<div>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2
  color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:blue'>Sharon</span></font></st1:City></st1:place><o:p></o:p></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, June 21, =
2006
5:23 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As a last call comment on RFC =
3280bis I
would like to raise the question whether RFC 3280bis should include an =
escape
clause clearly allowing relying parties to select what validation logic =
they
deploy on certificate validation.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The background is the fact that =
many deployed
PKIs are misconfigured.2<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>One such common misconfiguration is
assignment of certificate policies and their inclusion in CA =
certificates.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>X.509 path processing requires =
policies in
CA certificates to reflect the list of EE certificate policies that are =
valid
for a path. Yet many deployments have included pure CA certificate =
policies in
CA certificates, policies that are not included in any EE certificates =
and as
such, policy processing is not possible in such =
PKIs.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Application wanting to use =
certificate
policies in such PKI are simply forced to either fail or selectively =
neglect
certain path processing rules. For a relying party such modification =
could be
reasonable if the security implications has been well though =
through.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>However it is not clear if an
implementation allowing such local configuration could be regarded as =
standard
compliant.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are more examples where =
deploying
applications in misconfigured PKIs would need similar measures to =
work.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The pki4ipsec WG recently came to =
this
conclusion in their PKI profile and this lead to an intense debate which
included core participants from the PKIX =
WG.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The result was that the pki4ipsec =
profile
included an escape clause as follows:<o:p></o:p></span></font></p>

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

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>4.1.&nbsp; X.509 =
Certificates<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Users deploying IKE and IPsec =
with certificates have often had =
little<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; control over the capabilities of =
CAs available to them.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Implementations of this =
specification may include configuration =
knobs<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; to disable checks required by =
this specification in orde!<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> r =
t<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> o =
permit<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; use with inflexible and/or =
noncompliant CAs.&nbsp; However, all checks =
on<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; certificates exist for a =
specific reason involving the security =
of<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the entire system.&nbsp; =
Therefore, all checks MUST be enabled by =
default.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Administrators and users ought =
to understand the security purpose =
for<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the various checks, and be clear =
on what security will be lost =
by<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span styl! e=3D"FONT-SIZE: 10pt"><span
style=3D'font-size:10.0pt'>&nbsp;&nbsp; disabling the =
check.<o:p></o:p></span></font></pre></span>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I'm basically asking if RFC 3280bis =
path
validation needs a similar escape clause or corresponding clarification =
that
clearly allows local configuration of the validation =
logic.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>At least I think it is necessary to
clearly allow such configuration of standards compliant applications as =
long as
this is not the default functionality.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 16 juni 2006 =
22:42<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> last call for =
3280bis</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Folks,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Based on the latest message from David Cooper, I am initiating =
last
call on</span></font><font size=3D2><span style=3D'font-size:10.0pt'>
&quot;Internet X.509 Public Key Infrastructure, Certificate and =
Certificate
Revocation List (CRL) Profile&quot;</span></font><tt><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt'> =
(</span></font></tt><a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt=
"><font
size=3D2><span =
style=3D'font-size:10.0pt'>http://ietf.org/internet-drafts/draft-ietf-pki=
x-rfc3280bis-03.txt</span></font></a><font
size=3D2><span style=3D'font-size:10.0pt'>)</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>The last call will last for two weeks. In deference to the U.S.
Independence Dya holiday (which means July 3rd is a holiday for many =
folks),
all comments must be received by July 5th.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Steve</span></font><o:p></o:p></p>

</div>

</blockquote>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C6965F.1CC1663D--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N0dKtR005820; Thu, 22 Jun 2006 17:39:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5N0dKwu005818; Thu, 22 Jun 2006 17:39:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5N0dIFd005796 for <[e-mail]>; Thu, 22 Jun 2006 17:39:18 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 01:39:14 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6965D.732C5B0F"
Subject: RE: last call for 3280bis - escape clause
Date: Fri, 23 Jun 2006 01:39:12 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: last call for 3280bis - escape clause
thread-index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsAAAeBmuA=
From: "Stefan Santesson" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 23 Jun 2006 00:39:14.0040 (UTC) FILETIME=[737DFF80:01C6965D]
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_001_01C6965D.732C5B0F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Santosh,

=20

There are 2 distinct reasons why your approach is not a generic solution
to the problem.

=20

1)       The problem is generic and does not only apply to policy
processing. The pki4ipsec issue was e.g. motivated from problems with
EKU settings in existing certificates that does not satisfy new
applications and usages.

2)       If you need to test for a policy in the end certificate, that
policy will not be valid unless supported by the path, regardless if
policy constraints was set or not.

=20

In the perfect world, compliant path processing will always do the job.
In the real world, you may need to tweak the rules to make a new
application fit into an existing infrastructure-

=20

The question is still: Can a standards compliant implementation allow
configuration of non conformant modifications to the validation process,
or does that make the implementation as a whole non-conformant.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Santosh Chokhani
Sent: den 22 juni 2006 22:59
To: [e-mail]
Subject: RE: last call for 3280bis - escape clause

=20

Stefan,

=20

I agree with sentiments voiced by Steve, Rich, and Sharon.

=20

I have a simple solution to your concern from the relying party
viewpoint.  This observation is made with a long-held view of mine (and
no one had provided a convincing logical or business argument) that the
require explicit policy setting is a useless field.  A relying party can
always set acceptable policies to none.  In that scenario, (require
explicit policy) flag not withstanding, path validation will succeed.
Now, the user can examine the end certificate policy.

=20

You and I have had this discussion in another context.  The basic
premise is that if some field in the last certificate only is of
interest and the "state" in the path validation process does not impact
it, that need not be path of path validation engine.

=20

Thus, you can judiciously use the 3280 Engine and obtain the result you
seek.

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Guida, Richard [JJCUS]
Sent: Thursday, June 22, 2006 2:48 PM
To: Sharon Boeyen; 'Stefan Santesson'; [e-mail]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

=20

Stefan - perhaps I am missing something, but there is nothing that stops
a relying party from writing software that would perform processing
extensions only on CA certs as you propose.  As Sharon properly notes,
that would not be RFC3280 compliant - but a relying party can choose to
be non-compliant if it wishes.  And such non-compliance only puts the
relying party at risk, not others - so that is a "good thing" relatively
speaking.  But in the final analysis, seems to me that Sharon is
absolutely correct (assuming she and I are interpreting your proposal
properly) - unless X.509 is redefined, this would remain a circumstance
of non-compliance.  And so it should be treated as such.  Very best
regards -- Rich

=20

=20

=20

Richard A. Guida=20
Director, Information Security=20

Johnson & Johnson=20
Room GS8217=20
410 George Street=20
New Brunswick, New Jersey  08901=20
Phone:  [phone]=20

	-----Original Message-----
	From: [e-mail]
[mailto:[e-mail]]On Behalf Of Sharon Boeyen
	Sent: Thursday, June 22, 2006 1:57 PM
	To: 'Stefan Santesson'; [e-mail]
	Cc: Stephen Kent
	Subject: RE: last call for 3280bis - escape clause

	Stefan, if I understand your comment correctly I strongly
believe such an escape clause cannot possibly be added because this
would render 3280bis non-compliant with X.509.=20

	=20

	My understanding of your comment is that the escape clause would
enable a path validation engine to process the certificate policy OIDs
found in CA certificates but ignore those found in EE certificates. Is
that a correct understanding?=20

	=20

	If it is a correct understanding, then any such implementation
is non-conformant to X.509. 3280 is a profile of X.509 and as such can
mandate certain optional elements or exclude optional elements but
cannot reverse the mandatory processing from X.509.

	=20

	Apologies if I've misunderstood your question.

	=20

	Cheers,

	Sharon

		-----Original Message-----
		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
		Sent: Wednesday, June 21, 2006 5:23 PM
		To: [e-mail]
		Cc: Stephen Kent
		Subject: RE: last call for 3280bis - escape clause

		As a last call comment on RFC 3280bis I would like to
raise the question whether RFC 3280bis should include an escape clause
clearly allowing relying parties to select what validation logic they
deploy on certificate validation.

		=20

		The background is the fact that many deployed PKIs are
misconfigured.2

		One such common misconfiguration is assignment of
certificate policies and their inclusion in CA certificates.

		X.509 path processing requires policies in CA
certificates to reflect the list of EE certificate policies that are
valid for a path. Yet many deployments have included pure CA certificate
policies in CA certificates, policies that are not included in any EE
certificates and as such, policy processing is not possible in such
PKIs.

		=20

		Application wanting to use certificate policies in such
PKI are simply forced to either fail or selectively neglect certain path
processing rules. For a relying party such modification could be
reasonable if the security implications has been well though through.

		However it is not clear if an implementation allowing
such local configuration could be regarded as standard compliant.

		=20

		There are more examples where deploying applications in
misconfigured PKIs would need similar measures to work.

		=20

		The pki4ipsec WG recently came to this conclusion in
their PKI profile and this lead to an intense debate which included core
participants from the PKIX WG.

		=20

		The result was that the pki4ipsec profile included an
escape clause as follows:

		=20

		4.1.  X.509 Certificates
		=20
		   Users deploying IKE and IPsec with certificates have
often had little
		   control over the capabilities of CAs available to
them.
		   Implementations of this specification may include
configuration knobs
		   to disable checks required by this specification in
orde!
		 r t
		 o permit
		   use with inflexible and/or noncompliant CAs.
However, all checks on
		   certificates exist for a specific reason involving
the security of
		   the entire system.  Therefore, all checks MUST be
enabled by default.
		   Administrators and users ought to understand the
security purpose for
		   the various checks, and be clear on what security
will be lost by
		   disabling the check.

		=20

		=20

		I'm basically asking if RFC 3280bis path validation
needs a similar escape clause or corresponding clarification that
clearly allows local configuration of the validation logic.

		At least I think it is necessary to clearly allow such
configuration of standards compliant applications as long as this is not
the default functionality.

		=20

		=20

		Stefan Santesson

		Senior Program Manager

		Windows Security, Standards

	=09
________________________________


		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stephen Kent
		Sent: den 16 juni 2006 22:42
		To: [e-mail]
		Subject: last call for 3280bis

		=20

		Folks,

		=20

		Based on the latest message from David Cooper, I am
initiating last call on "Internet X.509 Public Key Infrastructure,
Certificate and Certificate Revocation List (CRL) Profile"
(http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt> )

		=20

		The last call will last for two weeks. In deference to
the U.S. Independence Dya holiday (which means July 3rd is a holiday for
many folks), all comments must be received by July 5th.

		=20

		Steve


------_=_NextPart_001_01C6965D.732C5B0F
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:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Message</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
tt
	{font-family:"Courier New";}
p.stylecentered, li.stylecentered, div.stylecentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:361246706;
	mso-list-type:hybrid;
	mso-list-template-ids:9974032 67698705 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are 2 distinct reasons why =
your
approach is not a generic solution to the =
problem.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 =
lfo3'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>1)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>The problem is generic and does not only apply to policy
processing. The pki4ipsec issue was e.g. motivated from problems with =
EKU
settings in existing certificates that does not satisfy new applications =
and
usages.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 =
lfo3'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>2)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>If you need to test for a policy in the end certificate, =
that
policy will not be valid unless supported by the path, regardless if =
policy constraints
was set or not.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In the perfect world, compliant =
path
processing will always do the job. In the real world, you may need to =
tweak the
rules to make a new application fit into an existing =
infrastructure-<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The question is still: Can a =
standards
compliant implementation allow configuration of non conformant =
modifications to
the validation process, or does that make the implementation as a whole =
non-conformant.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Santosh Chokhani<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 22 juni 2006 =
22:59<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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


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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree with sentiments voiced by =
Steve,
Rich, and Sharon.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I have a simple solution to your =
concern
from the relying party viewpoint.&nbsp; This observation is made with a =
long-held
view of mine (and no one had provided a convincing logical or business
argument) that the require explicit policy setting is a useless field. =
&nbsp;A
relying party can always set acceptable policies to none. &nbsp;In that
scenario, (require explicit policy) flag not withstanding, path =
validation will
succeed. &nbsp;Now, the user can examine the end certificate =
policy.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>You and I have had this discussion =
in
another context. &nbsp;The basic premise is that if some field in the =
last
certificate only is of interest and the &#8220;state&#8221; in the path
validation process does not impact it, that need not be path of path =
validation
engine.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thus, you can judiciously use the =
3280
Engine and obtain the result you seek.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Guida, Richard [JJCUS]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 2:48
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sharon Boeyen; =
'Stefan
Santesson'; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan - perhaps I am missing =
something,
but there is nothing that stops a relying party from writing software =
that
would perform processing extensions&nbsp;only on CA certs as you =
propose.&nbsp;
As <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Sharon</st1:City></st1:place>
properly notes, that would not be RFC3280 compliant - but a relying =
party can
choose to be non-compliant if it wishes.&nbsp; And such non-compliance =
only
puts the relying party at risk, not others - so that is&nbsp;a =
&quot;good
thing&quot; relatively speaking.&nbsp; But in the final analysis, seems =
to me
that <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Sharon</st1:City></st1:place> is
absolutely correct (assuming she and I are interpreting your proposal
properly)&nbsp;- unless X.509 is redefined, this would remain a =
circumstance of
non-compliance.&nbsp; And so it should be treated as&nbsp;such.&nbsp; =
Very best
regards -- Rich</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Richard A. Guida</span></font></b> <br>
<b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Director, Information Security</span></font></b> =
<o:p></o:p></p>

<p><b><i><font size=3D5 color=3Dred face=3D"Times New Roman"><span =
style=3D'font-size:
18.0pt;color:red;font-weight:bold;font-style:italic'>Johnson &amp; =
Johnson</span></font></i></b>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Room
GS8217</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>410 <st1:address
w:st=3D"on"><st1:Street w:st=3D"on">George Street</st1:Street><font =
size=3D3
 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;font-family:"Times New Roman"'>
 <br>
 </span></font><st1:City w:st=3D"on">New Brunswick</st1:City>, =
<st1:State w:st=3D"on">New
  Jersey</st1:State>&nbsp; <st1:PostalCode =
w:st=3D"on">08901</st1:PostalCode></st1:address></span></font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Phone:&nbsp;
732 524 3785</span></font> <o:p></o:p></p>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]]<b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Sharon Boeyen<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 1:57
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Stefan Santesson';
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan, if I understand your =
comment
correctly I strongly believe such an escape clause cannot possibly be =
added because
this would render 3280bis non-compliant with X.509. =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>My understanding of your comment is =
that
the escape clause would enable a path validation engine to process the
certificate policy OIDs found in CA certificates but ignore those found =
in EE
certificates. Is that a correct understanding? =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If it is a correct understanding, =
then any
such implementation is non-conformant to X.509. 3280 is a profile of =
X.509 and
as such can mandate certain optional elements or exclude optional =
elements but
cannot reverse the mandatory processing from =
X.509.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Apologies if I've misunderstood =
your
question.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

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


</div>

<div>

<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2
  color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:blue'>Sharon</span></font></st1:City></st1:place><o:p></o:p></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, June 21, =
2006
5:23 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As a last call comment on RFC =
3280bis I
would like to raise the question whether RFC 3280bis should include an =
escape clause
clearly allowing relying parties to select what validation logic they =
deploy on
certificate validation.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The background is the fact that =
many
deployed PKIs are misconfigured.2<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>One such common misconfiguration is =
assignment
of certificate policies and their inclusion in CA =
certificates.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>X.509 path processing requires =
policies in
CA certificates to reflect the list of EE certificate policies that are =
valid
for a path. Yet many deployments have included pure CA certificate =
policies in
CA certificates, policies that are not included in any EE certificates =
and as
such, policy processing is not possible in such =
PKIs.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Application wanting to use =
certificate
policies in such PKI are simply forced to either fail or selectively =
neglect
certain path processing rules. For a relying party such modification =
could be
reasonable if the security implications has been well though =
through.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>However it is not clear if an
implementation allowing such local configuration could be regarded as =
standard
compliant.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are more examples where =
deploying
applications in misconfigured PKIs would need similar measures to =
work.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The pki4ipsec WG recently came to =
this
conclusion in their PKI profile and this lead to an intense debate which =
included
core participants from the PKIX WG.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The result was that the pki4ipsec =
profile
included an escape clause as follows:<o:p></o:p></span></font></p>

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

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>4.1.&nbsp; X.509 =
Certificates<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Users deploying IKE and IPsec =
with certificates have often had =
little<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; control over the capabilities of =
CAs available to them.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Implementations of this =
specification may include configuration =
knobs<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; to disable checks required by =
this specification in orde!<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> r =
t<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> o =
permit<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; use with inflexible and/or =
noncompliant CAs.&nbsp; However, all checks =
on<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; certificates exist for a =
specific reason involving the security =
of<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the entire system.&nbsp; =
Therefore, all checks MUST be enabled by =
default.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Administrators and users ought =
to understand the security purpose =
for<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the various checks, and be clear =
on what security will be lost =
by<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span styl! e=3D"FONT-SIZE: 10pt"><span
style=3D'font-size:10.0pt'>&nbsp;&nbsp; disabling the =
check.<o:p></o:p></span></font></pre></span>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I'm basically asking if RFC 3280bis =
path
validation needs a similar escape clause or corresponding clarification =
that
clearly allows local configuration of the validation =
logic.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>At least I think it is necessary to
clearly allow such configuration of standards compliant applications as =
long as
this is not the default functionality.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 16 juni 2006 =
22:42<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> last call for =
3280bis</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Folks,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Based on the latest message from David Cooper, I am initiating =
last
call on</span></font><font size=3D2><span style=3D'font-size:10.0pt'>
&quot;Internet X.509 Public Key Infrastructure, Certificate and =
Certificate
Revocation List (CRL) Profile&quot;</span></font><tt><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt'> =
(</span></font></tt><a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt=
"><font
size=3D2><span =
style=3D'font-size:10.0pt'>http://ietf.org/internet-drafts/draft-ietf-pki=
x-rfc3280bis-03.txt</span></font></a><font
size=3D2><span style=3D'font-size:10.0pt'>)</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>The last call will last for two weeks. In deference to the U.S.
Independence Dya holiday (which means July 3rd is a holiday for many =
folks),
all comments must be received by July 5th.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Steve</span></font><o:p></o:p></p>

</div>

</blockquote>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C6965D.732C5B0F--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MNgqXo091713; Thu, 22 Jun 2006 16:42:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MNgqwJ091712; Thu, 22 Jun 2006 16:42:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org ([e-mail] [204.152.186.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MNgps6091705 for <[e-mail]>; Thu, 22 Jun 2006 16:42:52 -0700 (MST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k5MNgobs029939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jun 2006 23:42:50 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Thu, 22 Jun 2006 16:43:12 -0700
To: Tim Polk <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: stringprep in 3280bis
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <p06230906c0b8c72ccc06@[128.89.89.106]> <p06230906c0b8c72ccc06@[128.89.89.106]> <[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>

Tim,
  
As far as nameprep goes, yes, AllowUnassigned is all about
"stored" v. "query" strings.  So, as you note, domain
label preparation is mostly okay.  (see below comments).

However, I do note that 7.1 says nothing about "stored"
v. "query" strings.  In this case, as one implementation
is preparing both strings in the comparison, treating
both as "stored" should be fine.

-- Kurt

At 02:52 PM 6/22/2006, Tim Polk wrote:
>>To accommodate
>>   internationalized domain names in the current structure, conforming
>>   implementations MUST convert internationalized domain names to the
>>   ASCII Compatible Encoding (ACE) format as specified in section 4 of
>>   RFC 3490 before storage in the dNSName field.  Specifically,
>>   conforming implementations MUST perform the conversion operation
>>   specified in section 4 of RFC 3490 as follows:
>>
>>      * in step 1, the domain name SHALL be considered a "stored
>>      string";
> (additional steps deleted)

You might want to add:
        , hence the AllowUnassigned SHALL NOT be set.

since nameprep uses this flag to indicate the string has "stored"
handling.  Likewise in subsequent bullet set in this section.

>In section 7.3, we did not specify "stored" versus "query", because it does not seem to apply.  In this section 7.3, the domain component attribute contains only a single label, so we only perform the "ToASCII" operation.

It does (via AllowUnassigned).


>>To represent a label from an IDN in the distinguished
>>   name, the implementation MUST perform the "ToASCII" label conversion
>>   specified in section 4.1 of RFC 3490.
>
>As I said, the "ToASCII" operation doesn't seem to care about "stored" versus "query" so we didn't specify it.  However, the "ToASCII" operation does require specification of two additional inputs: the AllowUnassigned flag, and the UseSTD3ASCIIRules flag. We dropped the ball here.  We should have specified that the UseSTD3ASCIIRules flag should be set, and that AllowUassigned flag is *not* set.  (That works out to be the same as "stored" anyway, doesn't it?)

Yes.


>(1) How about the following revision to that sentence in 7.3:
>
>To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the STD3ASCIIRules flag is set but AllowUnassigned flag is not set.
>(2) If I misinterpreted the specification of "ToASCII", and we do need to specify "stored" vs. "query", we could use this alternate text:
>
>To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the string preparation is performed as a "stored" string.

I prefer language that explicitly says that the string is to be
regarded as "stored" and (hence) the AllowUnassigned flag is
not set (see my comment regarding 7.2 text).

-- Kurt 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MMoDqL078475; Thu, 22 Jun 2006 15:50:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MMoDPb078474; Thu, 22 Jun 2006 15:50:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MMoCcK078444 for <[e-mail]>; Thu, 22 Jun 2006 15:50:13 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2Hp029345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzu-0007u6-Dt; Thu, 22 Jun 2006 18:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-srvsan-02.txt 
Message-Id: <[e-mail]>
Date: Thu, 22 Jun 2006 18:50:02 -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 Subject Alternative Name for expression of service name
	Author(s)	: S. Santesson
	Filename	: draft-ietf-pkix-srvsan-02.txt
	Pages		: 11
	Date		: 2006-6-22
	
This document defines a new name form for inclusion in the otherName
filed of an X.509 Subject Alternative Name extension which allows a
certificate subject to be associated with the service name and domain
name components of a DNS Service Resource Record.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-srvsan-02.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-srvsan-02.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-srvsan-02.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MM4Afg067280; Thu, 22 Jun 2006 15:04:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MM4ABT067279; Thu, 22 Jun 2006 15:04:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MM48wG067236 for <[e-mail]>; Thu, 22 Jun 2006 15:04:09 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 23:04:00 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69647.C3E2A6F5"
Subject: RE: last call for 3280bis - escape clause
Date: Thu, 22 Jun 2006 23:03:58 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: last call for 3280bis - escape clause
thread-index: AcaWLJScwSTyVxSgTKS7ldtF72iXKAAGcqWw
From: "Stefan Santesson" <[e-mail]>
To: "Guida, Richard [JJCUS]" <[e-mail]>, "Sharon Boeyen" <[e-mail]>, <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>
X-OriginalArrivalTime: 22 Jun 2006 22:04:00.0569 (UTC) FILETIME=[C43B1A90:01C69647]
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_001_01C69647.C3E2A6F5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think my initial statement was a bit misinterpreted.

=20

I suggest no changes to RFC 3280 path processing. And of course,
skipping mandatory checks would make the path processing non-conformant.

=20

However. I have noticed that it is not clear to some people weather a
conformant implementation are forced to always do conformant path
processing, or if a conformant implementation can allow administrators
to turn of certain checking.

=20

What I say is mainly two things;

1)       Misconfigured PKIs may sometimes force relying parties to do
non conformant path processing or fail altogether.

2)       A conformant implementation should be allowed to support also
non-conformant processing as long as this is not the default behavior.

=20

I think this is already allowed, but some implementers may not read it
that way and therefore I'm asking if we should add a clarification like
pki4ipsec did.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: Guida, Richard [JJCUS] [mailto:[e-mail]]=20
Sent: den 22 juni 2006 20:48
To: Sharon Boeyen; Stefan Santesson; [e-mail]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

=20

Stefan - perhaps I am missing something, but there is nothing that stops
a relying party from writing software that would perform processing
extensions only on CA certs as you propose.  As Sharon properly notes,
that would not be RFC3280 compliant - but a relying party can choose to
be non-compliant if it wishes.  And such non-compliance only puts the
relying party at risk, not others - so that is a "good thing" relatively
speaking.  But in the final analysis, seems to me that Sharon is
absolutely correct (assuming she and I are interpreting your proposal
properly) - unless X.509 is redefined, this would remain a circumstance
of non-compliance.  And so it should be treated as such.  Very best
regards -- Rich

=20

=20

=20

Richard A. Guida=20
Director, Information Security=20

Johnson & Johnson=20
Room GS8217=20
410 George Street=20
New Brunswick, New Jersey  08901=20
Phone:  [phone]=20

	-----Original Message-----
	From: [e-mail]
[mailto:[e-mail]]On Behalf Of Sharon Boeyen
	Sent: Thursday, June 22, 2006 1:57 PM
	To: 'Stefan Santesson'; [e-mail]
	Cc: Stephen Kent
	Subject: RE: last call for 3280bis - escape clause

	Stefan, if I understand your comment correctly I strongly
believe such an escape clause cannot possibly be added because this
would render 3280bis non-compliant with X.509.=20

	=20

	My understanding of your comment is that the escape clause would
enable a path validation engine to process the certificate policy OIDs
found in CA certificates but ignore those found in EE certificates. Is
that a correct understanding?=20

	=20

	If it is a correct understanding, then any such implementation
is non-conformant to X.509. 3280 is a profile of X.509 and as such can
mandate certain optional elements or exclude optional elements but
cannot reverse the mandatory processing from X.509.

	=20

	Apologies if I've misunderstood your question.

	=20

	Cheers,

	Sharon

		-----Original Message-----
		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
		Sent: Wednesday, June 21, 2006 5:23 PM
		To: [e-mail]
		Cc: Stephen Kent
		Subject: RE: last call for 3280bis - escape clause

		As a last call comment on RFC 3280bis I would like to
raise the question whether RFC 3280bis should include an escape clause
clearly allowing relying parties to select what validation logic they
deploy on certificate validation.

		=20

		The background is the fact that many deployed PKIs are
misconfigured.2

		One such common misconfiguration is assignment of
certificate policies and their inclusion in CA certificates.

		X.509 path processing requires policies in CA
certificates to reflect the list of EE certificate policies that are
valid for a path. Yet many deployments have included pure CA certificate
policies in CA certificates, policies that are not included in any EE
certificates and as such, policy processing is not possible in such
PKIs.

		=20

		Application wanting to use certificate policies in such
PKI are simply forced to either fail or selectively neglect certain path
processing rules. For a relying party such modification could be
reasonable if the security implications has been well though through.

		However it is not clear if an implementation allowing
such local configuration could be regarded as standard compliant.

		=20

		There are more examples where deploying applications in
misconfigured PKIs would need similar measures to work.

		=20

		The pki4ipsec WG recently came to this conclusion in
their PKI profile and this lead to an intense debate which included core
participants from the PKIX WG.

		=20

		The result was that the pki4ipsec profile included an
escape clause as follows:

		=20

		4.1.  X.509 Certificates
		=20
		   Users deploying IKE and IPsec with certificates have
often had little
		   control over the capabilities of CAs available to
them.
		   Implementations of this specification may include
configuration knobs
		   to disable checks required by this specification in
orde!
		 r t
		 o permit
		   use with inflexible and/or noncompliant CAs.
However, all checks on
		   certificates exist for a specific reason involving
the security of
		   the entire system.  Therefore, all checks MUST be
enabled by default.
		   Administrators and users ought to understand the
security purpose for
		   the various checks, and be clear on what security
will be lost by
		   disabling the check.

		=20

		=20

		I'm basically asking if RFC 3280bis path validation
needs a similar escape clause or corresponding clarification that
clearly allows local configuration of the validation logic.

		At least I think it is necessary to clearly allow such
configuration of standards compliant applications as long as this is not
the default functionality.

		=20

		=20

		Stefan Santesson

		Senior Program Manager

		Windows Security, Standards

	=09
________________________________


		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stephen Kent
		Sent: den 16 juni 2006 22:42
		To: [e-mail]
		Subject: last call for 3280bis

		=20

		Folks,

		=20

		Based on the latest message from David Cooper, I am
initiating last call on "Internet X.509 Public Key Infrastructure,
Certificate and Certificate Revocation List (CRL) Profile"
(http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt> )

		=20

		The last call will last for two weeks. In deference to
the U.S. Independence Dya holiday (which means July 3rd is a holiday for
many folks), all comments must be received by July 5th.

		=20

		Steve


------_=_NextPart_001_01C69647.C3E2A6F5
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:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Message</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
tt
	{font-family:"Courier New";}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:990328973;
	mso-list-type:hybrid;
	mso-list-template-ids:1919843458 67698705 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I think my initial statement was a =
bit misinterpreted.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I suggest no changes to RFC 3280 =
path
processing. And of course, skipping mandatory checks would make the path
processing non-conformant.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>However. I have noticed that it is =
not
clear to some people weather a conformant implementation are forced to =
always do
conformant path processing, or if a conformant implementation can allow
administrators to turn of certain checking.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>What I say is mainly two =
things;<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>1)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>Misconfigured PKIs may sometimes force relying parties to do =
non
conformant path processing or fail =
altogether.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><span style=3D'mso-list:Ignore'>2)<font size=3D1 =
face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>A conformant implementation should be allowed to support =
also
non-conformant processing as long as this is not the default =
behavior.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I think this is already allowed, =
but some
implementers may not read it that way and therefore I&#8217;m asking if =
we
should add a clarification like pki4ipsec =
did.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Guida, Richard
[JJCUS] [mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 22 juni 2006 =
20:48<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sharon Boeyen; Stefan
Santesson; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan - perhaps I am missing =
something,
but there is nothing that stops a relying party from writing software =
that
would perform processing extensions&nbsp;only on CA certs as you =
propose.&nbsp;
As <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Sharon</st1:place></st1:City>
properly notes, that would not be RFC3280 compliant - but a relying =
party can
choose to be non-compliant if it wishes.&nbsp; And such non-compliance =
only
puts the relying party at risk, not others - so that is&nbsp;a =
&quot;good
thing&quot; relatively speaking.&nbsp; But in the final analysis, seems =
to me
that <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Sharon</st1:place></st1:City> is
absolutely correct (assuming she and I are interpreting your proposal
properly)&nbsp;- unless X.509 is redefined, this would remain a =
circumstance of
non-compliance.&nbsp; And so it should be treated as&nbsp;such.&nbsp; =
Very best
regards -- Rich</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Richard A. Guida</span></font></b> <br>
<b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Director, Information Security</span></font></b> =
<o:p></o:p></p>

<p><b><i><font size=3D5 color=3Dred face=3D"Times New Roman"><span =
style=3D'font-size:
18.0pt;color:red;font-weight:bold;font-style:italic'>Johnson &amp; =
Johnson</span></font></i></b>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Room
GS8217</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>410 <st1:address
w:st=3D"on"><st1:Street w:st=3D"on">George Street</st1:Street><font =
size=3D3
 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;font-family:"Times New Roman"'>
 <br>
 </span></font><st1:City w:st=3D"on">New Brunswick</st1:City>, =
<st1:State w:st=3D"on">New
  Jersey</st1:State>&nbsp; <st1:PostalCode =
w:st=3D"on">08901</st1:PostalCode></st1:address></span></font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Phone:&nbsp;
732 524 3785</span></font> <o:p></o:p></p>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]]<b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Sharon Boeyen<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 1:57
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Stefan Santesson';
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan, if I understand your =
comment correctly
I strongly believe such an escape clause cannot possibly be added =
because this
would render 3280bis non-compliant with X.509. =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>My understanding of your comment is =
that
the escape clause would enable a path validation engine to process the
certificate policy OIDs found in CA certificates but ignore those found =
in EE
certificates. Is that a correct understanding? =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If it is a correct understanding, =
then any
such implementation is non-conformant to X.509. 3280 is a profile of =
X.509 and
as such can mandate certain optional elements or exclude optional =
elements but
cannot reverse the mandatory processing from =
X.509.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Apologies if I've misunderstood =
your
question.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

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


</div>

<div>

<p class=3DMsoNormal><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font =
size=3D2
  color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:blue'>Sharon</span></font></st1:place></st1:City><o:p></o:p></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, June 21, =
2006
5:23 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As a last call comment on RFC =
3280bis I
would like to raise the question whether RFC 3280bis should include an =
escape
clause clearly allowing relying parties to select what validation logic =
they
deploy on certificate validation.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The background is the fact that =
many deployed
PKIs are misconfigured.2<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>One such common misconfiguration is
assignment of certificate policies and their inclusion in CA =
certificates.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>X.509 path processing requires =
policies in
CA certificates to reflect the list of EE certificate policies that are =
valid
for a path. Yet many deployments have included pure CA certificate =
policies in
CA certificates, policies that are not included in any EE certificates =
and as
such, policy processing is not possible in such =
PKIs.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Application wanting to use =
certificate
policies in such PKI are simply forced to either fail or selectively =
neglect
certain path processing rules. For a relying party such modification =
could be
reasonable if the security implications has been well though =
through.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>However it is not clear if an =
implementation
allowing such local configuration could be regarded as standard =
compliant.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are more examples where =
deploying
applications in misconfigured PKIs would need similar measures to =
work.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The pki4ipsec WG recently came to =
this
conclusion in their PKI profile and this lead to an intense debate which
included core participants from the PKIX =
WG.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The result was that the pki4ipsec =
profile
included an escape clause as follows:<o:p></o:p></span></font></p>

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

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>4.1.&nbsp; X.509 =
Certificates<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Users deploying IKE and IPsec =
with certificates have often had =
little<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; control over the capabilities of =
CAs available to them.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Implementations of this =
specification may include configuration =
knobs<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; to disable checks required by =
this specification in orde!<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> r =
t<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> o =
permit<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; use with inflexible and/or =
noncompliant CAs.&nbsp; However, all checks =
on<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; certificates exist for a =
specific reason involving the security =
of<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the entire system.&nbsp; =
Therefore, all checks MUST be enabled by =
default.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Administrators and users ought =
to understand the security purpose =
for<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the various checks, and be clear =
on what security will be lost =
by<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span styl! e=3D"FONT-SIZE: 10pt"><span
style=3D'font-size:10.0pt'>&nbsp;&nbsp; disabling the =
check.<o:p></o:p></span></font></pre></span>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I'm basically asking if RFC 3280bis =
path
validation needs a similar escape clause or corresponding clarification =
that
clearly allows local configuration of the validation =
logic.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>At least I think it is necessary to
clearly allow such configuration of standards compliant applications as =
long as
this is not the default functionality.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 16 juni 2006 =
22:42<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> last call for =
3280bis</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Folks,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Based on the latest message from David Cooper, I am initiating =
last
call on</span></font><font size=3D2><span style=3D'font-size:10.0pt'>
&quot;Internet X.509 Public Key Infrastructure, Certificate and =
Certificate
Revocation List (CRL) Profile&quot;</span></font><tt><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt'> =
(</span></font></tt><a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt=
"><font
size=3D2><span =
style=3D'font-size:10.0pt'>http://ietf.org/internet-drafts/draft-ietf-pki=
x-rfc3280bis-03.txt</span></font></a><font
size=3D2><span style=3D'font-size:10.0pt'>)</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>The last call will last for two weeks. In deference to the U.S.
Independence Dya holiday (which means July 3rd is a holiday for many =
folks),
all comments must be received by July 5th.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Steve</span></font><o:p></o:p></p>

</div>

</blockquote>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C69647.C3E2A6F5--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MLq9fZ064809; Thu, 22 Jun 2006 14:52:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MLq9C7064808; Thu, 22 Jun 2006 14:52:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MLq8rC064801 for <[e-mail]>; Thu, 22 Jun 2006 14:52:08 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5MLpv3O017927; Thu, 22 Jun 2006 17:51:57 -0400
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5MLpHrc004380; Thu, 22 Jun 2006 17:51:18 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 22 Jun 2006 17:52:56 -0400
To: "Kurt D. Zeilenga" <[e-mail]>, [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: stringprep in 3280bis
In-Reply-To: <[e-mail]>
References: <p06230906c0b8c72ccc06@[128.89.89.106]> <p06230906c0b8c72ccc06@[128.89.89.106]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [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>

Kurt,

To be fair, the I-D does address stored strings in a couple of places, 
although we may have missed a reference.  Please review the quotes below, 
along with a couple of alternatives for one update, to see if we have it 
right...

Section 7.2 of this I-D includes the following text:

>To accommodate
>    internationalized domain names in the current structure, conforming
>    implementations MUST convert internationalized domain names to the
>    ASCII Compatible Encoding (ACE) format as specified in section 4 of
>    RFC 3490 before storage in the dNSName field.  Specifically,
>    conforming implementations MUST perform the conversion operation
>    specified in section 4 of RFC 3490 as follows:
>
>       * in step 1, the domain name SHALL be considered a "stored
>       string";
  (additional steps deleted)

Sections 7.5 includes a reference to the text in 7.2.  From 7.5:

>    Where the host-part (the domain of the addr-spec) contains an
>    internationalized name, the domain name MUST be converted from an IDN
>    to the ASCII Compatible Encoding (ACE) format as specified in section
>    7.2.
>
>    Two email addresses are considered to match if:
>
>       1) the local-part of each name is an exact match, AND
>       2) the host-part of each name matches using a case-insensitive
>       ASCII comparison.

I am probably missing some nuance, but this would seem to be sufficient for 
sections 7.2 and 7.5.

In section 7.3, we did not specify "stored" versus "query", because it does 
not seem to apply.  In this section 7.3, the domain component attribute 
contains only a single label, so we only perform the "ToASCII" operation.

>To represent a label from an IDN in the distinguished
>    name, the implementation MUST perform the "ToASCII" label conversion
>    specified in section 4.1 of RFC 3490.

As I said, the "ToASCII" operation doesn't seem to care about "stored" 
versus "query" so we didn't specify it.  However, the "ToASCII" operation 
does require specification of two additional inputs: the AllowUnassigned 
flag, and the UseSTD3ASCIIRules flag. We dropped the ball here.  We should 
have specified that the UseSTD3ASCIIRules flag should be set, and that 
AllowUassigned flag is *not* set.  (That works out to be the same as 
"stored" anyway, doesn't it?)

(1) How about the following revision to that sentence in 7.3:

To represent a label from an IDN in the distinguished name, the 
implementation MUST perform the "ToASCII" label conversion specified in 
section 4.1 of RFC 3490, where the STD3ASCIIRules flag is set but 
AllowUnassigned flag is not set.

(2) If I misinterpreted the specification of "ToASCII", and we do need to 
specify "stored" vs. "query", we could use this alternate text:

To represent a label from an IDN in the distinguished name, the 
implementation MUST perform the "ToASCII" label conversion specified in 
section 4.1 of RFC 3490, where the string preparation is performed as a 
"stored" string.

Am I correct that 7.2 and 7.5 are okay?  What do you think of the 
alternatives for 7.3?

Thanks,

Tim

At 11:39 PM 6/21/2006 -0700, Kurt D. Zeilenga wrote:

>For various values, this I-D discusses how strings are to be
>prepared using various profiles of the StringPrep algorithm.
>However, the I-D fails to discuss whether the strings should
>be prepared as "stored" or "query" strings (see Section 4
>of RFC 3490).   The I-D should be revised so as to be clear
>which strings are to be treated as "stored" strings and which
>are to be treated as "query" strings.
>
>Off the cuff, I suspect the right thing to do is:
>   1) requiring each prepared string in a certificate/CRL be
>     treated as "stored", and
>   2) prepared strings to be compared against prepared strings
>   in a certificate/CRL to be treated as either "query" or "stored".
>This assures that each comparison between prepared strings
>involves at least one "stored" string.
>
>-- Kurt
>
>At 01:42 PM 6/16/2006, Stephen Kent wrote:
> >Folks,
> >
> >Based on the latest message from David Cooper, I am initiating last call 
> on "Internet X.509 Public Key Infrastructure, Certificate and Certificate 
> Revocation List (CRL) Profile" 
> (<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt>http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)
> >
> >The last call will last for two weeks. In deference to the U.S. 
> Independence Dya holiday (which means July 3rd is a holiday for many 
> folks), all comments must be received by July 5th.
> >
> >Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MKwe5t051373; Thu, 22 Jun 2006 13:58:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MKwegx051372; Thu, 22 Jun 2006 13:58:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MKwdiS051342 for <[e-mail]>; Thu, 22 Jun 2006 13:58:39 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6963F.1D4C93BD"
Subject: RE: last call for 3280bis - escape clause
Date: Thu, 22 Jun 2006 13:58:32 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: last call for 3280bis - escape clause
Thread-Index: AcaWNVMoloaBo6PDT0CPPD74liD0jQAB/dsA
From: "Santosh Chokhani" <[e-mail]>
To: <[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>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6963F.1D4C93BD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Stefan,

=20

I agree with sentiments voiced by Steve, Rich, and Sharon.

=20

I have a simple solution to your concern from the relying party
viewpoint.  This observation is made with a long-held view of mine (and
no one had provided a convincing logical or business argument) that the
require explicit policy setting is a useless field.  A relying party can
always set acceptable policies to none.  In that scenario, (require
explicit policy) flag not withstanding, path validation will succeed.
Now, the user can examine the end certificate policy.

=20

You and I have had this discussion in another context.  The basic
premise is that if some field in the last certificate only is of
interest and the "state" in the path validation process does not impact
it, that need not be path of path validation engine.

=20

Thus, you can judiciously use the 3280 Engine and obtain the result you
seek.

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Guida, Richard [JJCUS]
Sent: Thursday, June 22, 2006 2:48 PM
To: Sharon Boeyen; 'Stefan Santesson'; [e-mail]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause

=20

Stefan - perhaps I am missing something, but there is nothing that stops
a relying party from writing software that would perform processing
extensions only on CA certs as you propose.  As Sharon properly notes,
that would not be RFC3280 compliant - but a relying party can choose to
be non-compliant if it wishes.  And such non-compliance only puts the
relying party at risk, not others - so that is a "good thing" relatively
speaking.  But in the final analysis, seems to me that Sharon is
absolutely correct (assuming she and I are interpreting your proposal
properly) - unless X.509 is redefined, this would remain a circumstance
of non-compliance.  And so it should be treated as such.  Very best
regards -- Rich

=20

=20

=20

Richard A. Guida=20
Director, Information Security=20

Johnson & Johnson=20
Room GS8217=20
410 George Street=20
New Brunswick, New Jersey  08901=20
Phone:  [phone]=20

	-----Original Message-----
	From: [e-mail]
[mailto:[e-mail]]On Behalf Of Sharon Boeyen
	Sent: Thursday, June 22, 2006 1:57 PM
	To: 'Stefan Santesson'; [e-mail]
	Cc: Stephen Kent
	Subject: RE: last call for 3280bis - escape clause

	Stefan, if I understand your comment correctly I strongly
believe such an escape clause cannot possibly be added because this
would render 3280bis non-compliant with X.509.=20

	=20

	My understanding of your comment is that the escape clause would
enable a path validation engine to process the certificate policy OIDs
found in CA certificates but ignore those found in EE certificates. Is
that a correct understanding?=20

	=20

	If it is a correct understanding, then any such implementation
is non-conformant to X.509. 3280 is a profile of X.509 and as such can
mandate certain optional elements or exclude optional elements but
cannot reverse the mandatory processing from X.509.

	=20

	Apologies if I've misunderstood your question.

	=20

	Cheers,

	Sharon

		-----Original Message-----
		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
		Sent: Wednesday, June 21, 2006 5:23 PM
		To: [e-mail]
		Cc: Stephen Kent
		Subject: RE: last call for 3280bis - escape clause

		As a last call comment on RFC 3280bis I would like to
raise the question whether RFC 3280bis should include an escape clause
clearly allowing relying parties to select what validation logic they
deploy on certificate validation.

		=20

		The background is the fact that many deployed PKIs are
misconfigured.2

		One such common misconfiguration is assignment of
certificate policies and their inclusion in CA certificates.

		X.509 path processing requires policies in CA
certificates to reflect the list of EE certificate policies that are
valid for a path. Yet many deployments have included pure CA certificate
policies in CA certificates, policies that are not included in any EE
certificates and as such, policy processing is not possible in such
PKIs.

		=20

		Application wanting to use certificate policies in such
PKI are simply forced to either fail or selectively neglect certain path
processing rules. For a relying party such modification could be
reasonable if the security implications has been well though through.

		However it is not clear if an implementation allowing
such local configuration could be regarded as standard compliant.

		=20

		There are more examples where deploying applications in
misconfigured PKIs would need similar measures to work.

		=20

		The pki4ipsec WG recently came to this conclusion in
their PKI profile and this lead to an intense debate which included core
participants from the PKIX WG.

		=20

		The result was that the pki4ipsec profile included an
escape clause as follows:

		=20

		4.1.  X.509 Certificates
		=20
		   Users deploying IKE and IPsec with certificates have
often had little
		   control over the capabilities of CAs available to
them.
		   Implementations of this specification may include
configuration knobs
		   to disable checks required by this specification in
orde!
		 r t
		 o permit
		   use with inflexible and/or noncompliant CAs.
However, all checks on
		   certificates exist for a specific reason involving
the security of
		   the entire system.  Therefore, all checks MUST be
enabled by default.
		   Administrators and users ought to understand the
security purpose for
		   the various checks, and be clear on what security
will be lost by
		   disabling the check.

		=20

		=20

		I'm basically asking if RFC 3280bis path validation
needs a similar escape clause or corresponding clarification that
clearly allows local configuration of the validation logic.

		At least I think it is necessary to clearly allow such
configuration of standards compliant applications as long as this is not
the default functionality.

		=20

		=20

		Stefan Santesson

		Senior Program Manager

		Windows Security, Standards

	=09
________________________________


		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stephen Kent
		Sent: den 16 juni 2006 22:42
		To: [e-mail]
		Subject: last call for 3280bis

		=20

		Folks,

		=20

		Based on the latest message from David Cooper, I am
initiating last call on "Internet X.509 Public Key Infrastructure,
Certificate and Certificate Revocation List (CRL) Profile"
(http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt> )

		=20

		The last call will last for two weeks. In deference to
the U.S. Independence Dya holiday (which means July 3rd is a holiday for
many folks), all comments must be received by July 5th.

		=20

		Steve


------_=_NextPart_001_01C6963F.1D4C93BD
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:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Message</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"State"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
tt
	{font-family:"Courier New";}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

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


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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree with sentiments voiced by =
Steve,
Rich, and Sharon.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I have a simple solution to your =
concern
from the relying party viewpoint.&nbsp; This observation is made with a
long-held view of mine (and no one had provided a convincing logical or
business argument) that the require explicit policy setting is a useless =
field.
&nbsp;A relying party can always set acceptable policies to none. =
&nbsp;In that
scenario, (require explicit policy) flag not withstanding, path =
validation will
succeed. &nbsp;Now, the user can examine the end certificate =
policy.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>You and I have had this discussion =
in
another context. &nbsp;The basic premise is that if some field in the =
last
certificate only is of interest and the &#8220;state&#8221; in the path
validation process does not impact it, that need not be path of path =
validation
engine.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thus, you can judiciously use the =
3280
Engine and obtain the result you seek.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Guida, Richard =
[JJCUS]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 2:48
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sharon Boeyen; =
'Stefan
Santesson'; [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan - perhaps I am missing =
something,
but there is nothing that stops a relying party from writing software =
that
would perform processing extensions&nbsp;only on CA certs as you =
propose.&nbsp;
As <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Sharon</st1:place></st1:City>
properly notes, that would not be RFC3280 compliant - but a relying =
party can
choose to be non-compliant if it wishes.&nbsp; And such non-compliance =
only
puts the relying party at risk, not others - so that is&nbsp;a =
&quot;good
thing&quot; relatively speaking.&nbsp; But in the final analysis, seems =
to me
that <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Sharon</st1:place></st1:City> is
absolutely correct (assuming she and I are interpreting your proposal
properly)&nbsp;- unless X.509 is redefined, this would remain a =
circumstance of
non-compliance.&nbsp; And so it should be treated as&nbsp;such.&nbsp; =
Very best
regards -- Rich</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Richard A. Guida</span></font></b> <br>
<b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>Director, Information Security</span></font></b> =
<o:p></o:p></p>

<p><b><i><font size=3D5 color=3Dred face=3D"Times New Roman"><span =
style=3D'font-size:
18.0pt;color:red;font-weight:bold;font-style:italic'>Johnson &amp; =
Johnson</span></font></i></b>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Room
GS8217</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>410 <st1:address
w:st=3D"on"><st1:Street w:st=3D"on">George Street</st1:Street><font =
size=3D3
 face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;font-family:"Times New Roman"'>
 <br>
 </span></font><st1:City w:st=3D"on">New Brunswick</st1:City>, =
<st1:State w:st=3D"on">New
  Jersey</st1:State>&nbsp; <st1:PostalCode =
w:st=3D"on">08901</st1:PostalCode></st1:address></span></font>
<br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Phone:&nbsp;
732 524 3785</span></font> <o:p></o:p></p>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]]<b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Sharon Boeyen<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 22, =
2006 1:57
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Stefan Santesson';
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan, if I understand your =
comment correctly
I strongly believe such an escape clause cannot possibly be added =
because this
would render 3280bis non-compliant with X.509. =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>My understanding of your comment is =
that
the escape clause would enable a path validation engine to process the
certificate policy OIDs found in CA certificates but ignore those found =
in EE
certificates. Is that a correct understanding? =
</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>If it is a correct understanding, =
then any
such implementation is non-conformant to X.509. 3280 is a profile of =
X.509 and
as such can mandate certain optional elements or exclude optional =
elements but
cannot reverse the mandatory processing from =
X.509.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Apologies if I've misunderstood =
your
question.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

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


</div>

<div>

<p class=3DMsoNormal><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font =
size=3D2
  color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
  color:blue'>Sharon</span></font></st1:place></st1:City><o:p></o:p></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, June 21, =
2006
5:23 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: last call =
for 3280bis
- escape clause</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As a last call comment on RFC =
3280bis I
would like to raise the question whether RFC 3280bis should include an =
escape
clause clearly allowing relying parties to select what validation logic =
they
deploy on certificate validation.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The background is the fact that =
many
deployed PKIs are misconfigured.2<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>One such common misconfiguration is
assignment of certificate policies and their inclusion in CA =
certificates.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>X.509 path processing requires =
policies in
CA certificates to reflect the list of EE certificate policies that are =
valid
for a path. Yet many deployments have included pure CA certificate =
policies in
CA certificates, policies that are not included in any EE certificates =
and as
such, policy processing is not possible in such =
PKIs.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Application wanting to use =
certificate
policies in such PKI are simply forced to either fail or selectively =
neglect
certain path processing rules. For a relying party such modification =
could be
reasonable if the security implications has been well though =
through.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>However it is not clear if an
implementation allowing such local configuration could be regarded as =
standard
compliant.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are more examples where =
deploying
applications in misconfigured PKIs would need similar measures to =
work.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The pki4ipsec WG recently came to =
this
conclusion in their PKI profile and this lead to an intense debate which
included core participants from the PKIX =
WG.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The result was that the pki4ipsec =
profile
included an escape clause as follows:<o:p></o:p></span></font></p>

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

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>4.1.&nbsp; X.509 =
Certificates<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Users deploying IKE and IPsec =
with certificates have often had =
little<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; control over the capabilities of =
CAs available to them.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Implementations of this =
specification may include configuration =
knobs<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; to disable checks required by =
this specification in orde!<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> r =
t<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'> o =
permit<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; use with inflexible and/or =
noncompliant CAs.&nbsp; However, all checks =
on<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; certificates exist for a =
specific reason involving the security =
of<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the entire system.&nbsp; =
Therefore, all checks MUST be enabled by =
default.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Administrators and users ought =
to understand the security purpose =
for<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the various checks, and be clear =
on what security will be lost =
by<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span styl! e=3D"FONT-SIZE: 10pt"><span
style=3D'font-size:10.0pt'>&nbsp;&nbsp; disabling the =
check.<o:p></o:p></span></font></pre></span>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I'm basically asking if RFC 3280bis =
path
validation needs a similar escape clause or corresponding clarification =
that
clearly allows local configuration of the validation =
logic.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>At least I think it is necessary to
clearly allow such configuration of standards compliant applications as =
long as
this is not the default functionality.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 16 juni 2006 =
22:42<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> last call for =
3280bis</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Folks,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Based on the latest message from David Cooper, I am initiating =
last
call on</span></font><font size=3D2><span style=3D'font-size:10.0pt'> =
&quot;Internet
X.509 Public Key Infrastructure, Certificate and Certificate Revocation =
List
(CRL) Profile&quot;</span></font><tt><font size=3D2 face=3D"Courier =
New"><span
style=3D'font-size:10.0pt'> (</span></font></tt><a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt=
"><font
size=3D2><span =
style=3D'font-size:10.0pt'>http://ietf.org/internet-drafts/draft-ietf-pki=
x-rfc3280bis-03.txt</span></font></a><font
size=3D2><span style=3D'font-size:10.0pt'>)</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>The last call will last for two weeks. In deference to the U.S.
Independence Dya holiday (which means July 3rd is a holiday for many =
folks),
all comments must be received by July 5th.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Steve</span></font><o:p></o:p></p>

</div>

</blockquote>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C6963F.1D4C93BD--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MImdSa019852; Thu, 22 Jun 2006 11:48:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MImdJ6019851; Thu, 22 Jun 2006 11:48:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ncsusraimge01.jnj.com (ncsusraimge01.jnj.com [148.177.2.21]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MImcx2019827 for <[e-mail]>; Thu, 22 Jun 2006 11:48:38 -0700 (MST) (envelope-from [e-mail])
Received: from ncsusrawsa2.na.jnj.com ([10.4.21.2]) by ncsusraimge01.jnj.com (Switch-3.1.8/Switch-3.1.7) with SMTP id k5MIm87C010502; Thu, 22 Jun 2006 14:48:09 -0400 (EDT)
Received: from (10.4.20.168) by ncsusrawsa2.na.jnj.com via smtp id 2901_8ebc393a_0221_11db_8f25_0002b3ec9bcc; Thu, 22 Jun 2006 15:01:48 -0400
Received: by NCSUSRAEXIMS1.na.jnj.com with Internet Mail Service (5.5.2658.3) id <MLL76WP6>; Thu, 22 Jun 2006 14:48:08 -0400
Message-ID: <[e-mail]>
From: "Guida, Richard [JJCUS]" <[e-mail]>
To: Sharon Boeyen <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, [e-mail]
Cc: Stephen Kent <[e-mail]>
Subject: RE: last call for 3280bis - escape clause
Date: Thu, 22 Jun 2006 14:48:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2658.3)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6962C.6413C4C6"
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_01C6962C.6413C4C6
Content-Type: text/plain

Stefan - perhaps I am missing something, but there is nothing that stops a
relying party from writing software that would perform processing extensions
only on CA certs as you propose.  As Sharon properly notes, that would not
be RFC3280 compliant - but a relying party can choose to be non-compliant if
it wishes.  And such non-compliance only puts the relying party at risk, not
others - so that is a "good thing" relatively speaking.  But in the final
analysis, seems to me that Sharon is absolutely correct (assuming she and I
are interpreting your proposal properly) - unless X.509 is redefined, this
would remain a circumstance of non-compliance.  And so it should be treated
as such.  Very best regards -- Rich
 
 


Richard A. Guida 
Director, Information Security 

Johnson & Johnson 
Room GS8217 
410 George Street 
New Brunswick, New Jersey  08901 
Phone:  [phone] 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Sharon Boeyen
Sent: Thursday, June 22, 2006 1:57 PM
To: 'Stefan Santesson'; [e-mail]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause


Stefan, if I understand your comment correctly I strongly believe such an
escape clause cannot possibly be added because this would render 3280bis
non-compliant with X.509. 
 
My understanding of your comment is that the escape clause would enable a
path validation engine to process the certificate policy OIDs found in CA
certificates but ignore those found in EE certificates. Is that a correct
understanding? 
 
If it is a correct understanding, then any such implementation is
non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate
certain optional elements or exclude optional elements but cannot reverse
the mandatory processing from X.509.
 
Apologies if I've misunderstood your question.
 
Cheers,
Sharon

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Wednesday, June 21, 2006 5:23 PM
To: [e-mail]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause



As a last call comment on RFC 3280bis I would like to raise the question
whether RFC 3280bis should include an escape clause clearly allowing relying
parties to select what validation logic they deploy on certificate
validation.

 

The background is the fact that many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and
their inclusion in CA certificates.

X.509 path processing requires policies in CA certificates to reflect the
list of EE certificate policies that are valid for a path. Yet many
deployments have included pure CA certificate policies in CA certificates,
policies that are not included in any EE certificates and as such, policy
processing is not possible in such PKIs.

 

Application wanting to use certificate policies in such PKI are simply
forced to either fail or selectively neglect certain path processing rules.
For a relying party such modification could be reasonable if the security
implications has been well though through.

However it is not clear if an implementation allowing such local
configuration could be regarded as standard compliant.

 

There are more examples where deploying applications in misconfigured PKIs
would need similar measures to work.

 

The pki4ipsec WG recently came to this conclusion in their PKI profile and
this lead to an intense debate which included core participants from the
PKIX WG.

 

The result was that the pki4ipsec profile included an escape clause as
follows:

 

4.1.  X.509 Certificates
 
   Users deploying IKE and IPsec with certificates have often had little
   control over the capabilities of CAs available to them.
   Implementations of this specification may include configuration knobs
   to disable checks required by this specification in order t

 o permit
   use with inflexible and/or noncompliant CAs.  However, all checks on
   certificates exist for a specific reason involving the security of
   the entire system.  Therefore, all checks MUST be enabled by default.
   Administrators and users ought to understand the security purpose for
   the various checks, and be clear on what security will be lost by
   disabling the check.

 

 

I'm basically asking if RFC 3280bis path validation needs a similar escape
clause or corresponding clarification that clearly allows local
configuration of the validation logic.

At least I think it is necessary to clearly allow such configuration of
standards compliant applications as long as this is not the default
functionality.

 

 

Stefan Santesson

Senior Program Manager

Windows Security, Standards


  _____  


From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: den 16 juni 2006 22:42
To: [e-mail]
Subject: last call for 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating last call on
"Internet X.509 Public Key Infrastructure, Certificate and Certificate
Revocation List (CRL) Profile" (
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt>
http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence
Dya holiday (which means July 3rd is a holiday for many folks), all comments
must be received by July 5th.

 

Steve


------_=_NextPart_001_01C6962C.6413C4C6
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:dt = 
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1556" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
TT {
	FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=EN-US vLink=blue link=blue>
<DIV><SPAN class=803343518-22062006><FONT face=Arial color=#0000ff size=2>Stefan 
- perhaps I am missing something, but there is nothing that stops a relying 
party from writing software that would perform processing extensions&nbsp;only 
on CA certs as you propose.&nbsp; As Sharon properly notes, that would not be 
RFC3280 compliant - but a relying party can choose to be non-compliant if it 
wishes.&nbsp; And such non-compliance only puts the relying party at risk, not 
others - so that is&nbsp;a "good thing" relatively speaking.&nbsp; But in the 
final analysis, seems to me that Sharon is absolutely correct (assuming she and 
I are interpreting your proposal properly)&nbsp;- unless X.509 is redefined, 
this would remain a circumstance of non-compliance.&nbsp; And so it should be 
treated as&nbsp;such.&nbsp; Very best regards -- Rich</FONT></SPAN></DIV>
<DIV><SPAN class=803343518-22062006><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=803343518-22062006><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV><BR>
<P><B><FONT face=Arial size=2>Richard A. Guida</FONT></B> <BR><B><FONT 
face=Arial size=2>Director, Information Security</FONT></B> </P>
<P><B><I><FONT face="Times New Roman" color=#ff0000 size=5>Johnson &amp; 
Johnson</FONT></I></B><I></I> <BR><FONT face=Arial size=2>Room GS8217</FONT> 
<BR><FONT face=Arial size=2>410 George Street</FONT> <BR><FONT face=Arial 
size=2>New Brunswick, New Jersey&nbsp; 08901</FONT> <BR><FONT face=Arial 
size=2>Phone:&nbsp; 732 524 3785</FONT> </P>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> [e-mail] 
  [mailto:[e-mail]]<B>On Behalf Of </B>Sharon 
  Boeyen<BR><B>Sent:</B> Thursday, June 22, 2006 1:57 PM<BR><B>To:</B> 'Stefan 
  Santesson'; [e-mail]<BR><B>Cc:</B> Stephen Kent<BR><B>Subject:</B> 
  RE: last call for 3280bis - escape clause<BR><BR></FONT></DIV>
  <DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
  size=2>Stefan, if I understand your comment correctly I strongly believe such 
  an escape clause cannot possibly be added because this would render 3280bis 
  non-compliant with X.509. </FONT></SPAN></DIV>
  <DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff size=2>My 
  understanding of your comment is that the escape clause would enable a path 
  validation engine to process the certificate policy OIDs found in CA 
  certificates but ignore those found in EE certificates. Is that a correct 
  understanding? </FONT></SPAN></DIV>
  <DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff size=2>If 
  it is a correct understanding, then any such implementation is non-conformant 
  to X.509. 3280 is a profile of X.509 and as such can mandate certain optional 
  elements or exclude optional elements but cannot reverse the mandatory 
  processing from X.509.</FONT></SPAN></DIV>
  <DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
  size=2>Apologies if I've misunderstood your question.</FONT></SPAN></DIV>
  <DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
  size=2>Cheers,</FONT></SPAN></DIV>
  <DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
  size=2>Sharon</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
    face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
    [e-mail] [mailto:[e-mail]] <B>On 
    Behalf Of </B>Stefan Santesson<BR><B>Sent:</B> Wednesday, June 21, 2006 5:23 
    PM<BR><B>To:</B> [e-mail]<BR><B>Cc:</B> Stephen 
    Kent<BR><B>Subject:</B> RE: last call for 3280bis - escape 
    clause<BR><BR></FONT></DIV>
    <DIV class=Section1>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As a last call 
    comment on RFC 3280bis I would like to raise the question whether RFC 
    3280bis should include an escape clause clearly allowing relying parties to 
    select what validation logic they deploy on certificate 
    validation.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The background is 
    the fact that many deployed PKIs are 
    misconfigured.2<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">One such common 
    misconfiguration is assignment of certificate policies and their inclusion 
    in CA certificates.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">X.509 path 
    processing requires policies in CA certificates to reflect the list of EE 
    certificate policies that are valid for a path. Yet many deployments have 
    included pure CA certificate policies in CA certificates, policies that are 
    not included in any EE certificates and as such, policy processing is not 
    possible in such PKIs.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Application wanting 
    to use certificate policies in such PKI are simply forced to either fail or 
    selectively neglect certain path processing rules. For a relying party such 
    modification could be reasonable if the security implications has been well 
    though through.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">However it is not 
    clear if an implementation allowing such local configuration could be 
    regarded as standard compliant.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">There are more 
    examples where deploying applications in misconfigured PKIs would need 
    similar measures to work.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The pki4ipsec WG 
    recently came to this conclusion in their PKI profile and this lead to an 
    intense debate which included core participants from the PKIX 
    WG.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The result was that 
    the pki4ipsec profile included an escape clause as 
    follows:<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">4.1.&nbsp; X.509 Certificates<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; Users deploying IKE and IPsec with certificates have often had little<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; control over the capabilities of CAs available to them.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; Implementations of this specification may include configuration knobs<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; to disable checks required by this specification in orde!
 r t
 o permit<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; use with inflexible and/or noncompliant CAs.&nbsp; However, all checks on<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; certificates exist for a specific reason involving the security of<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; the entire system.&nbsp; Therefore, all checks MUST be enabled by default.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; Administrators and users ought to understand the security purpose for<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; the various checks, and be clear on what security will be lost by<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN styl!
 e="FONT-SIZE: 10pt">&nbsp;&nbsp; disabling the check.<o:p></o:p></SPAN></FONT></PRE>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I'm basically 
    asking if RFC 3280bis path validation needs a similar escape clause or 
    corresponding clarification that clearly allows local configuration of the 
    validation logic.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">At least I think it 
    is necessary to clearly allow such configuration of standards compliant 
    applications as long as this is not the default 
    functionality.<o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV>
    <P class=MsoNormal><STRONG><B><FONT face=Arial color=maroon size=3><SPAN 
    style="FONT-SIZE: 12pt; COLOR: maroon; FONT-FAMILY: Arial">Stefan 
    Santesson</SPAN></FONT></B></STRONG><FONT color=navy><SPAN 
    style="COLOR: navy"><o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><FONT face=Arial color=#400040 size=2><SPAN 
    style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: Arial">Senior Program 
    Manager</SPAN></FONT><FONT color=navy><SPAN 
    style="COLOR: navy"><o:p></o:p></SPAN></FONT></P>
    <P class=MsoNormal><STRONG><B><FONT face=Arial color=#400040 size=3><SPAN 
    style="FONT-SIZE: 12pt; COLOR: #400040; FONT-FAMILY: Arial">Windows 
    Security, Standards</SPAN></FONT></B></STRONG><o:p></o:p></P></DIV>
    <DIV>
    <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT 
    face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
    <HR tabIndex=-1 align=center width="100%" SIZE=2>
    </SPAN></FONT></DIV>
    <P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN 
    style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT 
    face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> 
    [e-mail] [mailto:[e-mail]] <B><SPAN 
    style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Stephen Kent<BR><B><SPAN 
    style="FONT-WEIGHT: bold">Sent:</SPAN></B> den 16 juni 2006 
    22:42<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> 
    [e-mail]<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> 
    last call for 3280bis</SPAN></FONT><o:p></o:p></P></DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt">Folks,<o:p></o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt">Based on the latest message from David Cooper, I am 
    initiating last call on</SPAN></FONT><FONT size=2><SPAN 
    style="FONT-SIZE: 10pt"> "Internet X.509 Public Key Infrastructure, 
    Certificate and Certificate Revocation List (CRL) 
    Profile"</SPAN></FONT><TT><FONT face="Courier New" size=2><SPAN 
    style="FONT-SIZE: 10pt"> (</SPAN></FONT></TT><A 
    href="http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt"><FONT 
    size=2><SPAN 
    style="FONT-SIZE: 10pt">http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt</SPAN></FONT></A><FONT 
    size=2><SPAN style="FONT-SIZE: 10pt">)</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=2><SPAN 
    style="FONT-SIZE: 10pt">&nbsp;</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=2><SPAN 
    style="FONT-SIZE: 10pt">The last call will last for two weeks. In deference 
    to the U.S. Independence Dya holiday (which means July 3rd is a holiday for 
    many folks), all comments must be received by July 
    5th.</SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
    style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
    <DIV>
    <P class=MsoNormal><FONT face="Times New Roman" size=2><SPAN 
    style="FONT-SIZE: 10pt">Steve</SPAN></FONT><o:p></o:p></P></DIV></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6962C.6413C4C6--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MIW2AL015867; Thu, 22 Jun 2006 11:32:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MIW2E7015866; Thu, 22 Jun 2006 11:32:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MIW1k2015847 for <[e-mail]>; Thu, 22 Jun 2006 11:32:02 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5MIVtNr002537; Thu, 22 Jun 2006 14:31:56 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5MIVh7Q004261; Thu, 22 Jun 2006 14:31:43 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 14:32:20 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Seth Hitchings <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-scvp-26.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [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>

Seth Hitchings wrote:

>Should the CMS reference in section 11.1 be updated to RFC 3852?
>  
>
Seth,

Yes.  I believe that the [CMS] reference should be updated from 3369 to 
3852.  Also, the [UTF8] reference should be updated from 2279 to 3629 
and the [IKE] reference should be updated from 2409 to 4306.

Updating the [UTF8] and [IKE] should only affect the References section.

Updating the [CMS] reference will also require changing the ASN.1 in 
section 8 so that ContentInfo is imported from the 
CryptographicMessageSyntax2004 module rather than the 
CryptographicMessageSyntax, but I don't think that should cause any 
problems.

Dave



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MIV3Ts015703; Thu, 22 Jun 2006 11:31:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MIV2Ds015702; Thu, 22 Jun 2006 11:31:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MIV1NV015673 for <[e-mail]>; Thu, 22 Jun 2006 11:31:02 -0700 (MST) (envelope-from [e-mail])
Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id AF4C06807D; Thu, 22 Jun 2006 19:30:55 +0100 (IST)
Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A05076A3367; Thu, 22 Jun 2006 19:30:55 +0100
Received: from [134.226.144.16] (unknown [134.226.144.16]) by imx2.tcd.ie (Postfix) with ESMTP id 847E16807D; Thu, 22 Jun 2006 19:30:55 +0100 (IST)
Message-ID: <[e-mail]>
Date: Thu, 22 Jun 2006 19:31:21 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Sharon Boeyen <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>, [e-mail]
Subject: Re: last call for 3280bis - escape clause
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: MessageID = A15076A3367
X-AntiVirus-Status: Host: imx2.tcd.ie
X-AntiVirus-Status: Action Taken: 
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.56.3 VDF=8.1230)
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 guess I'd agree with Sharon's conclusion but for slightly different
reasons. If people need such a different profile of x.509 or 3280bis
then a different RFC is required IMO - given that 3280 exists it would
be wrong for 3280bis to include such a change since you'd potentially
punish 3280 implementers for being compliant.

Stephen.

Sharon Boeyen wrote:
> Stefan, if I understand your comment correctly I strongly believe such 
> an escape clause cannot possibly be added because this would render 
> 3280bis non-compliant with X.509.
>  
> My understanding of your comment is that the escape clause would enable 
> a path validation engine to process the certificate policy OIDs found in 
> CA certificates but ignore those found in EE certificates. Is that a 
> correct understanding?
>  
> If it is a correct understanding, then any such implementation is 
> non-conformant to X.509. 3280 is a profile of X.509 and as such can 
> mandate certain optional elements or exclude optional elements but 
> cannot reverse the mandatory processing from X.509.
>  
> Apologies if I've misunderstood your question.
>  
> Cheers,
> Sharon
> 
>     -----Original Message-----
>     *From:* [e-mail]
>     [mailto:[e-mail]] *On Behalf Of *Stefan Santesson
>     *Sent:* Wednesday, June 21, 2006 5:23 PM
>     *To:* [e-mail]
>     *Cc:* Stephen Kent
>     *Subject:* RE: last call for 3280bis - escape clause
> 
>     As a last call comment on RFC 3280bis I would like to raise the
>     question whether RFC 3280bis should include an escape clause clearly
>     allowing relying parties to select what validation logic they deploy
>     on certificate validation.
> 
>      
> 
>     The background is the fact that many deployed PKIs are misconfigured.2
> 
>     One such common misconfiguration is assignment of certificate
>     policies and their inclusion in CA certificates.
> 
>     X.509 path processing requires policies in CA certificates to
>     reflect the list of EE certificate policies that are valid for a
>     path. Yet many deployments have included pure CA certificate
>     policies in CA certificates, policies that are not included in any
>     EE certificates and as such, policy processing is not possible in
>     such PKIs.
> 
>      
> 
>     Application wanting to use certificate policies in such PKI are
>     simply forced to either fail or selectively neglect certain path
>     processing rules. For a relying party such modification could be
>     reasonable if the security implications has been well though through.
> 
>     However it is not clear if an implementation allowing such local
>     configuration could be regarded as standard compliant.
> 
>      
> 
>     There are more examples where deploying applications in
>     misconfigured PKIs would need similar measures to work.
> 
>      
> 
>     The pki4ipsec WG recently came to this conclusion in their PKI
>     profile and this lead to an intense debate which included core
>     participants from the PKIX WG.
> 
>      
> 
>     The result was that the pki4ipsec profile included an escape clause
>     as follows:
> 
>      
> 
>     4.1.  X.509 Certificates
> 
>      
> 
>        Users deploying IKE and IPsec with certificates have often had little
> 
>        control over the capabilities of CAs available to them.
> 
>        Implementations of this specification may include configuration knobs
> 
>        to disable checks required by this specification in order t
>      o permit
> 
>        use with inflexible and/or noncompliant CAs.  However, all checks on
> 
>        certificates exist for a specific reason involving the security of
> 
>        the entire system.  Therefore, all checks MUST be enabled by default.
> 
>        Administrators and users ought to understand the security purpose for
> 
>        the various checks, and be clear on what security will be lost by
> 
>        disabling the check.
> 
>      
> 
>      
> 
>     I'm basically asking if RFC 3280bis path validation needs a similar
>     escape clause or corresponding clarification that clearly allows
>     local configuration of the validation logic.
> 
>     At least I think it is necessary to clearly allow such configuration
>     of standards compliant applications as long as this is not the
>     default functionality.
> 
>      
> 
>      
> 
>     **Stefan Santesson**
> 
>     Senior Program Manager
> 
>     **Windows Security, Standards**
> 
>     ------------------------------------------------------------------------
> 
>     *From:* [e-mail]
>     [mailto:[e-mail]] *On Behalf Of *Stephen Kent
>     *Sent:* den 16 juni 2006 22:42
>     *To:* [e-mail]
>     *Subject:* last call for 3280bis
> 
>      
> 
>     Folks,
> 
>      
> 
>     Based on the latest message from David Cooper, I am initiating last
>     call on "Internet X.509 Public Key Infrastructure, Certificate and
>     Certificate Revocation List (CRL) Profile"
>     (http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)
> 
>      
> 
>     The last call will last for two weeks. In deference to the U.S.
>     Independence Dya holiday (which means July 3rd is a holiday for many
>     folks), all comments must be received by July 5th.
> 
>      
> 
>     Steve
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MHv9q0006884; Thu, 22 Jun 2006 10:57:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MHv9eN006883; Thu, 22 Jun 2006 10:57:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sottsym2.entrust.com (sottsym2.entrust.com [216.191.252.20]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MHv8Bc006854 for <[e-mail]>; Thu, 22 Jun 2006 10:57:08 -0700 (MST) (envelope-from [e-mail])
Received: from sottmxsecs3.entrust.com (unknown [216.191.252.14]) by sottsym2.entrust.com (Symantec Mail Security) with SMTP id 10202240002 for <[e-mail]>; Thu, 22 Jun 2006 13:57:02 -0400 (EDT)
Received: (qmail 26259 invoked from network); 22 Jun 2006 17:57:01 -0000
Received: from [e-mail] by sottmxsecs3.entrust.com with EntrustECS-Server-7.4;22 Jun 2006 17:57:01 -0000
Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 22 Jun 2006 17:57:00 -0000
Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id <M0M5CB7H>; Thu, 22 Jun 2006 13:57:01 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, [e-mail]
Cc: Stephen Kent <[e-mail]>
Subject: RE: last call for 3280bis - escape clause
Date: Thu, 22 Jun 2006 13:56:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69624.D29D3652"
X-Brightmail-Tracker: AAAAAA==
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_01C69624.D29D3652
Content-Type: text/plain

Stefan, if I understand your comment correctly I strongly believe such an
escape clause cannot possibly be added because this would render 3280bis
non-compliant with X.509. 
 
My understanding of your comment is that the escape clause would enable a
path validation engine to process the certificate policy OIDs found in CA
certificates but ignore those found in EE certificates. Is that a correct
understanding? 
 
If it is a correct understanding, then any such implementation is
non-conformant to X.509. 3280 is a profile of X.509 and as such can mandate
certain optional elements or exclude optional elements but cannot reverse
the mandatory processing from X.509.
 
Apologies if I've misunderstood your question.
 
Cheers,
Sharon

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Wednesday, June 21, 2006 5:23 PM
To: [e-mail]
Cc: Stephen Kent
Subject: RE: last call for 3280bis - escape clause



As a last call comment on RFC 3280bis I would like to raise the question
whether RFC 3280bis should include an escape clause clearly allowing relying
parties to select what validation logic they deploy on certificate
validation.

 

The background is the fact that many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies and
their inclusion in CA certificates.

X.509 path processing requires policies in CA certificates to reflect the
list of EE certificate policies that are valid for a path. Yet many
deployments have included pure CA certificate policies in CA certificates,
policies that are not included in any EE certificates and as such, policy
processing is not possible in such PKIs.

 

Application wanting to use certificate policies in such PKI are simply
forced to either fail or selectively neglect certain path processing rules.
For a relying party such modification could be reasonable if the security
implications has been well though through.

However it is not clear if an implementation allowing such local
configuration could be regarded as standard compliant.

 

There are more examples where deploying applications in misconfigured PKIs
would need similar measures to work.

 

The pki4ipsec WG recently came to this conclusion in their PKI profile and
this lead to an intense debate which included core participants from the
PKIX WG.

 

The result was that the pki4ipsec profile included an escape clause as
follows:

 

4.1.  X.509 Certificates
 
   Users deploying IKE and IPsec with certificates have often had little
   control over the capabilities of CAs available to them.
   Implementations of this specification may include configuration knobs
   to disable checks required by this specification in order to permit
   use with inflexible and/or noncompliant CAs.  However, all checks on
   certificates exist for a specific reason involving the security of
   the entire system.  Therefore, all checks MUST be enabled by default.
   Administrators and users ought to understand the security purpose for
   the various checks, and be clear on what security will be lost by
   disabling the check.

 

 

I'm basically asking if RFC 3280bis path validation needs a similar escape
clause or corresponding clarification that clearly allows local
configuration of the validation logic.

At least I think it is necessary to clearly allow such configuration of
standards compliant applications as long as this is not the default
functionality.

 

 

Stefan Santesson

Senior Program Manager

Windows Security, Standards


  _____  


From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: den 16 juni 2006 22:42
To: [e-mail]
Subject: last call for 3280bis

 

Folks,

 

Based on the latest message from David Cooper, I am initiating last call on
"Internet X.509 Public Key Infrastructure, Certificate and Certificate
Revocation List (CRL) Profile" (
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt>
http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)

 

The last call will last for two weeks. In deference to the U.S. Independence
Dya holiday (which means July 3rd is a holiday for many folks), all comments
must be received by July 5th.

 

Steve


------_=_NextPart_001_01C69624.D29D3652
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word" xmlns:dt = 
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2900.2912" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
TT {
	FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=EN-US vLink=blue link=blue>
<DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
size=2>Stefan, if I understand your comment correctly I strongly believe such an 
escape clause cannot possibly be added because this would render 3280bis 
non-compliant with X.509. </FONT></SPAN></DIV>
<DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff size=2>My 
understanding of your comment is that the escape clause would enable a path 
validation engine to process the certificate policy OIDs found in CA 
certificates but ignore those found in EE certificates. Is that a correct 
understanding? </FONT></SPAN></DIV>
<DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff size=2>If it 
is a correct understanding, then any such implementation is non-conformant to 
X.509. 3280 is a profile of X.509 and as such can mandate certain optional 
elements or exclude optional elements but cannot reverse the mandatory 
processing from X.509.</FONT></SPAN></DIV>
<DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
size=2>Apologies if I've misunderstood your question.</FONT></SPAN></DIV>
<DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
size=2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=698515317-22062006><FONT face=Arial color=#0000ff 
size=2>Sharon</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
  [e-mail] [mailto:[e-mail]] <B>On 
  Behalf Of </B>Stefan Santesson<BR><B>Sent:</B> Wednesday, June 21, 2006 5:23 
  PM<BR><B>To:</B> [e-mail]<BR><B>Cc:</B> Stephen 
  Kent<BR><B>Subject:</B> RE: last call for 3280bis - escape 
  clause<BR><BR></FONT></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As a last call 
  comment on RFC 3280bis I would like to raise the question whether RFC 3280bis 
  should include an escape clause clearly allowing relying parties to select 
  what validation logic they deploy on certificate 
  validation.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The background is the 
  fact that many deployed PKIs are misconfigured.2<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">One such common 
  misconfiguration is assignment of certificate policies and their inclusion in 
  CA certificates.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">X.509 path processing 
  requires policies in CA certificates to reflect the list of EE certificate 
  policies that are valid for a path. Yet many deployments have included pure CA 
  certificate policies in CA certificates, policies that are not included in any 
  EE certificates and as such, policy processing is not possible in such 
  PKIs.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Application wanting 
  to use certificate policies in such PKI are simply forced to either fail or 
  selectively neglect certain path processing rules. For a relying party such 
  modification could be reasonable if the security implications has been well 
  though through.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">However it is not 
  clear if an implementation allowing such local configuration could be regarded 
  as standard compliant.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">There are more 
  examples where deploying applications in misconfigured PKIs would need similar 
  measures to work.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The pki4ipsec WG 
  recently came to this conclusion in their PKI profile and this lead to an 
  intense debate which included core participants from the PKIX 
  WG.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The result was that 
  the pki4ipsec profile included an escape clause as 
  follows:<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">4.1.&nbsp; X.509 Certificates<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; Users deploying IKE and IPsec with certificates have often had little<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; control over the capabilities of CAs available to them.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; Implementations of this specification may include configuration knobs<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; to disable checks required by this specification in order t
 o permit<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; use with inflexible and/or noncompliant CAs.&nbsp; However, all checks on<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; certificates exist for a specific reason involving the security of<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; the entire system.&nbsp; Therefore, all checks MUST be enabled by default.<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; Administrators and users ought to understand the security purpose for<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style="FONT-SIZE: 10pt">&nbsp;&nbsp; the various checks, and be clear on what security will be lost by<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face="Courier New" size=2><SPAN style
 ="FONT-SIZE: 10pt">&nbsp;&nbsp; disabling the check.<o:p></o:p></SPAN></FONT></PRE>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I'm basically asking 
  if RFC 3280bis path validation needs a similar escape clause or corresponding 
  clarification that clearly allows local configuration of the validation 
  logic.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">At least I think it 
  is necessary to clearly allow such configuration of standards compliant 
  applications as long as this is not the default 
  functionality.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=MsoNormal><STRONG><B><FONT face=Arial color=maroon size=3><SPAN 
  style="FONT-SIZE: 12pt; COLOR: maroon; FONT-FAMILY: Arial">Stefan 
  Santesson</SPAN></FONT></B></STRONG><FONT color=navy><SPAN 
  style="COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=#400040 size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: #400040; FONT-FAMILY: Arial">Senior Program 
  Manager</SPAN></FONT><FONT color=navy><SPAN 
  style="COLOR: navy"><o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><STRONG><B><FONT face=Arial color=#400040 size=3><SPAN 
  style="FONT-SIZE: 12pt; COLOR: #400040; FONT-FAMILY: Arial">Windows Security, 
  Standards</SPAN></FONT></B></STRONG><o:p></o:p></P></DIV>
  <DIV>
  <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT 
  face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
  <HR tabIndex=-1 align=center width="100%" SIZE=2>
  </SPAN></FONT></DIV>
  <P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT 
  face=Tahoma size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> 
  [e-mail] [mailto:[e-mail]] <B><SPAN 
  style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Stephen Kent<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Sent:</SPAN></B> den 16 juni 2006 22:42<BR><B><SPAN 
  style="FONT-WEIGHT: bold">To:</SPAN></B> [e-mail]<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Subject:</SPAN></B> last call for 
  3280bis</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">Folks,<o:p></o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt">Based on the latest message from David Cooper, I am 
  initiating last call on</SPAN></FONT><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt"> "Internet X.509 Public Key Infrastructure, 
  Certificate and Certificate Revocation List (CRL) 
  Profile"</SPAN></FONT><TT><FONT face="Courier New" size=2><SPAN 
  style="FONT-SIZE: 10pt"> (</SPAN></FONT></TT><A 
  href="http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt"><FONT 
  size=2><SPAN 
  style="FONT-SIZE: 10pt">http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt</SPAN></FONT></A><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">)</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">&nbsp;</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">The last call will last for two weeks. In deference to 
  the U.S. Independence Dya holiday (which means July 3rd is a holiday for many 
  folks), all comments must be received by July 
  5th.</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
  <DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=2><SPAN 
  style="FONT-SIZE: 10pt">Steve</SPAN></FONT><o:p></o:p></P></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C69624.D29D3652--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MEUiIZ054214; Thu, 22 Jun 2006 07:30:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MEUiZa054213; Thu, 22 Jun 2006 07:30:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MEUh9C054176 for <[e-mail]>; Thu, 22 Jun 2006 07:30:43 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: draft-ietf-pkix-scvp-26.txt
Date: Thu, 22 Jun 2006 10:30:33 -0400
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0AB8_01C695E6.E4331ED0"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-scvp-26.txt
Thread-Index: AcaRfvKveO66k8aZRGyMmcjJ6nlwlgEiVwPA
From: "Seth Hitchings" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "pkix" <[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>

This is a multi-part message in MIME format.

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

Should the CMS reference in section 11.1 be updated to RFC 3852? 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of David A. Cooper
Sent: Friday, June 16, 2006 3:38 PM
To: pkix
Subject: draft-ietf-pkix-scvp-26.txt


All,

I have just submitted draft 26 of SCVP for posting.  The draft should be
available soon, but in the meantime, I have posted a diff file highlighting
the differences between drafts 24 and 26 (the only difference between drafts
24 and 25 was the correction of a typographical error in section 3.6).  The
diff file is available at
http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-24_to_26.
html.

Drafts 24 and 26 differ in the following places:

1) Section 3: corrected cross-reference ("3.10" replaced by "3.11").

2) Section 3.2.4.2.3 (Name Validation Algorithm):  Matching rules for use
with id-kp-serverAuth are now specified in the document rather than
referring to the matching rules in RFC 2818 [HTTP-TLS].  (RFC 2818 is an
Informational RFC and so SCVP could not include a normative reference to
that document).

3) Section 3.6: "requestorName" replaced with "responderName".  (This was
the typographical error that was corrected in draft 25.)

4) Section 4: A new sentence was added to clarify that when a protected
response is required, the SCVP server must use SignedData or
AuthenticatedData even if the response is being sent over a protected
transport (e.g., TLS).

5) Section 11.1 (Normative References):  The reference to RFC 2818 was
deleted.


None of these changes to the document result in any changes to the protocol.


Dave


------=_NextPart_000_0AB8_01C695E6.E4331ED0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIVzCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCAw0wggJ2oAMCAQICAXwwDQYJKoZI
hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE
AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDUwODI5MTQyNTQwWhcNMDYw
OTEyMTQyNTQwWjBqMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRcwFQYD
VQQDEw5TZXRoIEhpdGNoaW5nczEoMCYGCSqGSIb3DQEJARYZc2hpdGNoaW5nc0Bjb3Jlc3RyZWV0
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzZOhlCd/KDWl33RR6dW+YKFd8Kof1Uz8
9wJ3EevLEK73npZfKDj66mL6fQOL1Cv1RaQrucsm8ZB2bMvUDRvoeC1Te4xsHvxNyV8AoEbxYWsK
QciJCNM5bd6kkpfgummUBCgUs7nze+FNhIzWGerlMUjcc37diSOD+FP24WXU+zUCAwEAAaOB2jCB
1zAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5nZW90cnVzdC5j
b20vY3Jscy9jb3Jlc3RyZWV0LmNybDAkBgNVHREEHTAbgRlzaGl0Y2hpbmdzQGNvcmVzdHJlZXQu
Y29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAGCCsGAQUFBwEBBDQwMjAwBggr
BgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0cmVldC5jb20vMA0GCSqGSIb3DQEB
BQUAA4GBAHPT6HnJxaWD8+WdUL//eXEekqR0rio7r2OdTJ4VSrWZQRHMkWmOzG8aPvgGX7SMh0QZ
TvcSBNY7h43m5fPNk7Jaxy+F3LbdwHu02NM/IiUBsLyn8XXi03Xekni5PT6aDuP/Egux3nnlKjej
mMjDOVTNBwKwF/QfjP+QViQTO6hoMYICmTCCApUCAQEwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UE
ChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhv
cml0eQIBfDAJBgUrDgMCGgUAoIIBmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wNjA2MjIxNDMwMzNaMCMGCSqGSIb3DQEJBDEWBBQtWddj/xhrUQO1v6jY5Q4kqZJc
STBmBgkrBgEEAYI3EAQxWTBXMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0
ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgF8MGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCyqGSIb3DQEJEAILMVmg
VzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3Jl
U3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBfDANBgkqhkiG9w0BAQEFAASBgH1TCj1VuI07
8+CN5yRAxYcc8qlNy7o9wqd3yPaigGJyYSuStaeOog+1ElheaWUMnp/iNf9EjLvv8w6bqwvN1WWg
YhPUDaoR9yoF7/k/fdl4G/FvRE62N2hWNs/fbIAi70hLJjQJCGd4OMbHrJ0rYXNZ16hvpbb74pPT
ftihee9+AAAAAAAA

------=_NextPart_000_0AB8_01C695E6.E4331ED0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MCqUGK031868; Thu, 22 Jun 2006 05:52:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5MCqUcf031867; Thu, 22 Jun 2006 05:52:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MCqSuq031849 for <[e-mail]>; Thu, 22 Jun 2006 05:52:29 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 13:52:24 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C695FA.B565663B"
Subject: RE: last call for 3280bis - references
Date: Thu, 22 Jun 2006 13:52:22 +0100
Message-ID: <[e-mail]>
In-Reply-To: <p06230906c0b8c72ccc06@[128.89.89.106]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: last call for 3280bis - references
thread-index: AcaRi3NPpHbHqjJkRuqLU85fpb+OdAEbxWwQ
From: "Stefan Santesson" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 22 Jun 2006 12:52:24.0838 (UTC) FILETIME=[B5A35260:01C695FA]
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_001_01C695FA.B565663B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In general we need a work through of the reference section to get the
references up to date.

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: den 16 juni 2006 22:42
To: [e-mail]
Subject: last call for 3280bis

=20

Folks,

=20

Based on the latest message from David Cooper, I am initiating last call
on "Internet X.509 Public Key Infrastructure, Certificate and
Certificate Revocation List (CRL) Profile"
(http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt> )

=20

The last call will last for two weeks. In deference to the U.S.
Independence Dya holiday (which means July 3rd is a holiday for many
folks), all comments must be received by July 5th.

=20

Steve


------_=_NextPart_001_01C695FA.B565663B
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=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>last call for 3280bis</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
tt
	{font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In general we need a work through =
of the
reference section to get the references up to =
date.<o:p></o:p></span></font></p>

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 16 juni 2006 =
22:42<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> last call for =
3280bis</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Folks,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Based on the latest message from David Cooper, I am initiating =
last
call on</span></font><font size=3D2><span style=3D'font-size:10.0pt'>
&quot;Internet X.509 Public Key Infrastructure, Certificate and =
Certificate
Revocation List (CRL) Profile&quot;</span></font><tt><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt'> =
(</span></font></tt><a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt=
"><font
size=3D2><span =
style=3D'font-size:10.0pt'>http://ietf.org/internet-drafts/draft-ietf-pki=
x-rfc3280bis-03.txt</span></font></a><font
size=3D2><span style=3D'font-size:10.0pt'>)</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>The last call will last for two weeks. In deference to the U.S.
Independence Dya holiday (which means July 3rd is a holiday for many =
folks),
all comments must be received by July 5th.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Steve</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C695FA.B565663B--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5M6dWLT052137; Wed, 21 Jun 2006 23:39:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5M6dW19052136; Wed, 21 Jun 2006 23:39:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org ([e-mail] [204.152.186.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5M6dVUJ052130 for <[e-mail]>; Wed, 21 Jun 2006 23:39:31 -0700 (MST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k5M6dUTj062145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 22 Jun 2006 06:39:30 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 21 Jun 2006 23:39:58 -0700
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: stringprep in 3280bis
In-Reply-To: <p06230906c0b8c72ccc06@[128.89.89.106]>
References: <p06230906c0b8c72ccc06@[128.89.89.106]>
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>

For various values, this I-D discusses how strings are to be
prepared using various profiles of the StringPrep algorithm.
However, the I-D fails to discuss whether the strings should
be prepared as "stored" or "query" strings (see Section 4
of RFC 3490).   The I-D should be revised so as to be clear
which strings are to be treated as "stored" strings and which
are to be treated as "query" strings.

Off the cuff, I suspect the right thing to do is:
  1) requiring each prepared string in a certificate/CRL be
    treated as "stored", and
  2) prepared strings to be compared against prepared strings
  in a certificate/CRL to be treated as either "query" or "stored".
This assures that each comparison between prepared strings
involves at least one "stored" string.

-- Kurt

At 01:42 PM 6/16/2006, Stephen Kent wrote:
>Folks,
>
>Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt>http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)
> 
>The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th.
>
>Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5LLN2ow006867; Wed, 21 Jun 2006 14:23:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5LLN2jN006866; Wed, 21 Jun 2006 14:23:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5LLN0EY006837 for <[e-mail]>; Wed, 21 Jun 2006 14:23:00 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 22:22:54 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69578.DB4D2429"
Subject: RE: last call for 3280bis - escape clause
Date: Wed, 21 Jun 2006 22:22:53 +0100
Message-ID: <[e-mail]>
In-Reply-To: <p06230906c0b8c72ccc06@[128.89.89.106]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: last call for 3280bis - escape clause
thread-index: AcaRi3NPpHbHqjJkRuqLU85fpb+OdADywY5Q
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>
X-OriginalArrivalTime: 21 Jun 2006 21:22:54.0165 (UTC) FILETIME=[DBB9F850:01C69578]
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_001_01C69578.DB4D2429
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

As a last call comment on RFC 3280bis I would like to raise the question
whether RFC 3280bis should include an escape clause clearly allowing
relying parties to select what validation logic they deploy on
certificate validation.

=20

The background is the fact that many deployed PKIs are misconfigured.2

One such common misconfiguration is assignment of certificate policies
and their inclusion in CA certificates.

X.509 path processing requires policies in CA certificates to reflect
the list of EE certificate policies that are valid for a path. Yet many
deployments have included pure CA certificate policies in CA
certificates, policies that are not included in any EE certificates and
as such, policy processing is not possible in such PKIs.

=20

Application wanting to use certificate policies in such PKI are simply
forced to either fail or selectively neglect certain path processing
rules. For a relying party such modification could be reasonable if the
security implications has been well though through.

However it is not clear if an implementation allowing such local
configuration could be regarded as standard compliant.

=20

There are more examples where deploying applications in misconfigured
PKIs would need similar measures to work.

=20

The pki4ipsec WG recently came to this conclusion in their PKI profile
and this lead to an intense debate which included core participants from
the PKIX WG.

=20

The result was that the pki4ipsec profile included an escape clause as
follows:

=20

4.1.  X.509 Certificates
=20
   Users deploying IKE and IPsec with certificates have often had little
   control over the capabilities of CAs available to them.
   Implementations of this specification may include configuration knobs
   to disable checks required by this specification in order to permit
   use with inflexible and/or noncompliant CAs.  However, all checks on
   certificates exist for a specific reason involving the security of
   the entire system.  Therefore, all checks MUST be enabled by default.
   Administrators and users ought to understand the security purpose for
   the various checks, and be clear on what security will be lost by
   disabling the check.

=20

=20

I'm basically asking if RFC 3280bis path validation needs a similar
escape clause or corresponding clarification that clearly allows local
configuration of the validation logic.

At least I think it is necessary to clearly allow such configuration of
standards compliant applications as long as this is not the default
functionality.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stephen Kent
Sent: den 16 juni 2006 22:42
To: [e-mail]
Subject: last call for 3280bis

=20

Folks,

=20

Based on the latest message from David Cooper, I am initiating last call
on "Internet X.509 Public Key Infrastructure, Certificate and
Certificate Revocation List (CRL) Profile"
(http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt
<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt> )

=20

The last call will last for two weeks. In deference to the U.S.
Independence Dya holiday (which means July 3rd is a holiday for many
folks), all comments must be received by July 5th.

=20

Steve


------_=_NextPart_001_01C69578.DB4D2429
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:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>last call for 3280bis</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
tt
	{font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>As a last call comment on RFC =
3280bis I
would like to raise the question whether RFC 3280bis should include an =
escape
clause clearly allowing relying parties to select what validation logic =
they
deploy on certificate validation.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The background is the fact that =
many
deployed PKIs are misconfigured.2<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>One such common misconfiguration is
assignment of certificate policies and their inclusion in CA =
certificates.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>X.509 path processing requires =
policies in
CA certificates to reflect the list of EE certificate policies that are =
valid
for a path. Yet many deployments have included pure CA certificate =
policies in
CA certificates, policies that are not included in any EE certificates =
and as
such, policy processing is not possible in such =
PKIs.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Application wanting to use =
certificate
policies in such PKI are simply forced to either fail or selectively =
neglect
certain path processing rules. For a relying party such modification =
could be
reasonable if the security implications has been well though =
through.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>However it is not clear if an
implementation allowing such local configuration could be regarded as =
standard
compliant.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>There are more examples where =
deploying
applications in misconfigured PKIs would need similar measures to =
work.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The pki4ipsec WG recently came to =
this conclusion
in their PKI profile and this lead to an intense debate which included =
core participants
from the PKIX WG.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The result was that the pki4ipsec =
profile
included an escape clause as follows:<o:p></o:p></span></font></p>

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

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>4.1.&nbsp; X.509 =
Certificates<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Users deploying IKE and IPsec =
with certificates have often had =
little<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; control over the capabilities of =
CAs available to them.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Implementations of this =
specification may include configuration =
knobs<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; to disable checks required by =
this specification in order to =
permit<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; use with inflexible and/or =
noncompliant CAs.&nbsp; However, all checks =
on<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; certificates exist for a =
specific reason involving the security =
of<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the entire system.&nbsp; =
Therefore, all checks MUST be enabled by =
default.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; Administrators and users ought =
to understand the security purpose =
for<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; the various checks, and be clear =
on what security will be lost =
by<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp; disabling the =
check.<o:p></o:p></span></font></pre>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I&#8217;m basically asking if RFC =
3280bis
path validation needs a similar escape clause or corresponding =
clarification
that clearly allows local configuration of the validation =
logic.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>At least I think it is necessary to =
clearly
allow such configuration of standards compliant applications as long as =
this is
not the default functionality.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:12.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stephen Kent<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 16 juni 2006 =
22:42<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> last call for =
3280bis</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Folks,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Based on the latest message from David Cooper, I am initiating =
last
call on</span></font><font size=3D2><span style=3D'font-size:10.0pt'>
&quot;Internet X.509 Public Key Infrastructure, Certificate and =
Certificate
Revocation List (CRL) Profile&quot;</span></font><tt><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt'> =
(</span></font></tt><a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt=
"><font
size=3D2><span =
style=3D'font-size:10.0pt'>http://ietf.org/internet-drafts/draft-ietf-pki=
x-rfc3280bis-03.txt</span></font></a><font
size=3D2><span style=3D'font-size:10.0pt'>)</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>The last call will last for two weeks. In deference to the U.S.
Independence Dya holiday (which means July 3rd is a holiday for many =
folks),
all comments must be received by July 5th.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:
10.0pt'>Steve</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C69578.DB4D2429--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5LFBC2t098753; Wed, 21 Jun 2006 08:11:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5LFBBXE098747; Wed, 21 Jun 2006 08:11:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5LFBACi098716 for <[e-mail]>; Wed, 21 Jun 2006 08:11:10 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 17028 invoked from network); 21 Jun 2006 15:11:04 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.17.105.223 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 21 Jun 2006 15:11:04 -0000
Reply-To: <[e-mail]>
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt
Date: Wed, 21 Jun 2006 11:10:28 -0400
Organization: IECA, Inc.
Message-ID: <02e701c69544$d53fc9c0$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Thread-Index: AcaVRNSF7z4+d1M7Q42pTFUyTJy++g==
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 as follows (r=replace):

1. Abstract: To the sentence beginning with "The X.509 v3 CRL format is
described in detail," add "an Internet specific extension is defined,".  AIA
is an internet specific extension. 

2. Sec 1 para 7 last sentence: replace a conforming certificate/conforming
certificates.  There are three cert examples in Appendix C.

3. Sec 1 last *, Sec 8, and Sec 10: r RFC 2510/RFC 4210

4. Sec 4 1st para last sentence: remove required to support a PKI.  All of
the internet defined extensions are optional so they can't be required to
support a PKI for the internet community.

5. Sec 4.1.2.4 last para penultimate and last sentence: r section
7.1/section 7.1 and 7.3.  7.3 needs to be added as issuer names can be
expressed using the domainComponent attribute.

6. Sec 4.2.1.2: Can we suggest using something other than SHA-1 for key id
generation? How about striking SHA-1 from the methods and adding the new
sentence to both: The hash algorithm employed can be the same algorithm
paired with the signature algorithm (e.g., SHA-1, SHA-256, SHA-384).

7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that since
the SAN is bound to the public key that the CA MUST verify the each part of
the SAN. I think a similar statement ought to be added to the subject
section (4.1.2.6) to indicate that "All parts of the subject name MUST be
verified by the CA as it is bound to the public key".

8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name
constraints on ediPartyName or registeredID but the 14th para (the one
before the ASN.1) indicates that ediPartyName and registeredId are not
defined in this spec but MAY be defined in another spec. Sounds to me like
it would be hard to convince a customer that you could write a name
constraints that can ever be 3280bis compliant since whatever you wrote MUST
NOT be imposed/implemented. It's not clear that the name constraints
shouldn't be imposed because they're not defined in the spec or whether they
should never ever be imposed.

9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name
constraints on x400Address name forms but the last sentence in the 10th para
last says X400Address MUST be applied to x.400 addresses. See #8.

10. Sec 4.2.2.1 4th to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP
[RFC 2255] URI. Makes it consistent with AIA in CRL section.

11. Sec 4.2.2.2 3rd to last para: r HTTP or LDAP URI/HTTP [RFC 1738] or LDAP
[RFC 2255] URI.  Makes it consistent with AIA sections.

12. Sec 5 3rd to last para: r This profile does not define any private
Internet CRL extensions or CRL entry extensions/This profiles defines one
CRL extension and no CRL entry extensions.  AIA is defined in this spec.

13. Sec 5.2.5 8th para (one before the ASN.1): The sentence about the
onlyContainsAttributeCerts seems to hang. Recommend adding "In either case"
to the beginning of the sentence to address the case when either
onlyContainsUserCerts or onlyContainsCACerts is set to TRUE. Additionally,
recommend adding the following for completeness as a new last paragraph: "If
the scope of the CRL only includes attribute certificates then the
onlyContainsAttributeCerts MUST be set to TRUE and both
onlyContainsUserCerts and onlyContainsCACerts MUST be set to FALSE."

14. Sec 5.2.7: Remove ASN.1.  It's already referenced in the 1st para,
duplication leads to errors, and the other sections that reused ASN.1 from
certificate sections did not duplicate the ASN.1 (see AKI/IAN).

15. Sec 5.3.1: Can we add an ASN.1 comment to say the enumerated value #7 is
never used?

16. Sec 4.2.1.6 1st para: r These identities may be included in addition to
or in the place of the identity/These identities may be included in addition
to or in the place of, in the case of non-CAs, the identity.  The paragraph
mixes SAN and IAN, but assumed the 2nd sentence addressed SAN.

17. Sec 4.2.1.6: Add the following to clarify that there is no dependency in
this spec between SAN and IAN: This specification places no requirement on
CAs, whose certificate includes Issuer Alterative name, to include Subject
Alternative names in certificates issued by the CA. 

18. Sec 4.2.1.7: Add the following three sentences to be explicit about the
checks not made: Issuer Alternative names are not constrained by name
constraints. If a CA certificate has a Subject Alternative name, the
specification does not require CAs to populate the Issuer Alternative name
in certificates issued by the CA. Further, the chain of Issuer Alternative
and Subject Alternative names, as is done with issuer and subject names, is
not checked during the certificate path validation algorithm in section 6.

19. Sec 5.2.2: Add the following: Issuer Alternative names are not
constrained by name constraints. If a CA certificate has a Subject
Alternative name, this specification does not require CAs to populate the
Issuer Alternative name in CRLs issued by the CA.

Feel free to wordsmith any of the suggested text.

spt




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5KNV91j075511; Tue, 20 Jun 2006 16:31:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5KNV9cb075510; Tue, 20 Jun 2006 16:31:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org ([e-mail] [204.152.186.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5KNV8SF075503 for <[e-mail]>; Tue, 20 Jun 2006 16:31:08 -0700 (MST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k5KNV781069208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jun 2006 23:31:07 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Tue, 20 Jun 2006 16:31:02 -0700
To: Michael Ströder <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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>

At 01:44 AM 6/20/2006, Michael Ströder wrote:
>Reference to RFC 2253 should be updated since it
>was obsoleted by RFC 4514 recently.


In the same vein...

The document's reference to RFC 2247 should be replaced with a
reference RFC 4419.  RFC 4419 replaces that portion of RFC 2247
referenced.

The document's reference to draft-ietf-ldapbis-strprep-07.txt
should be updated to RFC 4518.
The document's reference to RFC 2255 should be replaced with
RFC 4516.

THe document's reference to RFC 2587 should be replaced with
RFC 4523.
The document's reference to RFC 1778 should be removed (not used).

The document's reference to RFC 2252 should be replaced with
RFC 4512, which now specifies the <numericoid> syntax.

The document's reference to RFC 2279 should be replaced with
a reference to RFC 3629.

Regarding the included ASN.1 modules, it might be appropriate
to add a copyright comment, e.g.:
        -- Copyright (C) The Internet Society (2006).  This version of  
        -- this ASN.1 module is part of RFC XXXX; see the RFC itself    
        -- for full legal notices.


>Ciao, Michael.
>
>[e-mail] wrote:
>> 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 Certificate and Certificate Revocation List (CRL) Profile
>>       Author(s)       : D. Cooper, et al.
>>       Filename        : draft-ietf-pkix-rfc3280bis-03.txt
>>       Pages           : 141
>>       Date            : 2006-5-24



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5KCMxIS039828; Tue, 20 Jun 2006 05:22:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5KCMxdY039827; Tue, 20 Jun 2006 05:22:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5KCMv2K039812 for <[e-mail]>; Tue, 20 Jun 2006 05:22:57 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:22:56 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69464.4267ACF2"
Subject: PKXIX draft agenda
Date: Tue, 20 Jun 2006 13:22:55 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PKXIX draft agenda
thread-index: AcaT9zRONeDYsIOCRrmh/diZJYCbnQAZ+Ybg
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>
X-OriginalArrivalTime: 20 Jun 2006 12:22:56.0365 (UTC) FILETIME=[42B841D0:01C69464]
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_001_01C69464.4267ACF2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

=20

Here is the draft PKIX agenda for the 66th IETF.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20

=20

---------------------------------------------

=20

PKIX WG (pkix-wg)

http://ietf.org/html.charters/pkix-charter.html

=20

=20

MONDAY, July 10, 2006 1520-1720 (Room 519b)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=20

CHAIR: Stephen Kent <[e-mail]>, Stefan Santesson
<[e-mail]>

=20

AGENDA:

=20

1. WG Status and Direction

=20

1.1 Document Status Review (5 min.)

      Stefan Santesson (WG co-chair)

=20

      Some WG documents are with the Ads, some are in RFC editors queue=20

      and a few are still within the WG development process. (10 min.)

=20

2. PKIX WG Specifications=20

=20

  2.1 Simple Certificate Validation Protocol (SCVP) (10 min.)

      David Cooper (NIST)

        http://ietf.org/internet-drafts/draft-ietf-pkix-scvp-25.txt

=20

      This document is in AD evaluation state with some final issues
still under discussion

=20

  2.2 3280bis (15 min.)

      David Cooper (NIST)

=20
http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt

=20

      A new draft 03 was recently posted and WG last call has been
initiated.

=20

  2.3 Algorithm IDs for Elliptic Curve Cryptography in PKIX (10 min.)

     Daniel Brown (Certicom)

=20
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-02.txt

=20

     Some issues concerning algorithm identifiers are yet to be
determined

=20

  2.5 Subject Identification Method (SIM) [Agneda item not decided yet]
(5 min.)

      Tim Polk (NIST)

        http://ietf.org/internet-drafts/draft-ietf-pkix-sim-07.txt

=20

      Past IETF last Call. A new draft is requested by IESG.

=20

  2.6 Additional Algorithms and Identifiers for DSA and ECDSA (5 min.)

      Tim Polk (NIST)

=20
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.tx
t

=20

     A new -00 draft has just been posted.

=20

=20

3. Related Specifications & Liaison Presentations

=20

      Time allowing, liaison presentations will be accommodated to
ensure the

      PKIX WG is aware of related specifications currently progressing
as

      individual drafts.

=20

  3.1 Including the AIA extension in attribute certificates (10 min)

      David Chadwick (University of Kent)

=20

      A presentation about including the AIA extension in attribute
certificates,=20

      and the requirement to find the superior AA of the AC issuer, as
well as the=20

      signing certificate of the issuer of the AC

=20

=20

4. Joint PKIX/SIDR Meeting

   http://ietf.org/html.charters/sidr-charter.html

=20

  4.1 Address Space & As Number PKI (60 min.)

      Stephen Kent (BBN)

=20

     This presentation will review the current plans and status for
creating a PKI

     that reflects the allocation of resources through Regional Internet
Registries.

     The motivation for creation this PKI is to enable better security
for Internet

     routing (BGP).

=20

=20

=20

=20


------_=_NextPart_001_01C69464.4267ACF2
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceName"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PlaceType"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Here is the draft PKIX agenda for =
the 66<sup>th</sup>
IETF.<o:p></o:p></span></font></p>

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

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

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier =
New"'>---------------------------------------------<o:p></o:p></span></fo=
nt></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>PKIX WG =
(pkix-wg)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><a
href=3D"http://ietf.org/html.charters/pkix-charter.html">http://ietf.org/=
html.charters/pkix-charter.html</a><o:p></o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>MONDAY, July 10, 2006 1520-1720 (Room =
519b)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier =
New"'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></=
span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>CHAIR: Stephen Kent &lt;[e-mail]&gt;, =
Stefan
Santesson &lt;<font color=3Dnavy><span =
style=3D'color:navy'>stefans</span></font>@<font
color=3Dnavy><span style=3D'color:navy'>microsoft</span></font>.<font =
color=3Dnavy><span
style=3D'color:navy'>com</span></font>&gt;<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>AGENDA:<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>1. WG Status and =
Direction<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>1.1 Document Status Review (5 =
min.)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stefan =
Santesson (WG
co-chair)<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Some WG =
documents are
with the Ads, some are in RFC editors queue =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and a few are =
still
within the WG development process. </span></font><font size=3D2 =
face=3D"Courier New"><span
lang=3DSV style=3D'font-size:10.0pt;font-family:"Courier New"'>(10 =
min.)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span lang=3DSV
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span lang=3DSV
style=3D'font-size:10.0pt;font-family:"Courier New"'>2. PKIX WG =
Specifications <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span lang=3DSV
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;2.1 Simple Certificate Validation
Protocol (SCVP) (10 min.)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; David Cooper =
(NIST)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; <a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-scvp-25.txt"
title=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-scvp-25.txt">htt=
p://ietf.org/internet-drafts/draft-ietf-pkix-scvp-25.txt</a><o:p></o:p></=
span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This document =
is in
AD evaluation state with some final issues still under =
discussion<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp; 2.2 3280bis (15 =
min.)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; David Cooper =
(NIST)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; <a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt=
"
title=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.tx=
t">http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt</a><=
o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A new draft 03 =
was
recently posted and WG last call has been =
initiated.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp; 2.3 Algorithm IDs for Elliptic Curve
Cryptography in PKIX (10 min.)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp; Daniel Brown =
(Certicom)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-02=
.txt"
title=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-0=
2.txt">http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-02.=
txt</a><o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp; Some issues =
concerning algorithm
identifiers are yet to be determined<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp; 2.5 Subject Identification Method =
(SIM)
[Agneda item not decided yet] (5 min.)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tim Polk =
(NIST)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-sim-07.txt"
title=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-sim-07.txt">http=
://ietf.org/internet-drafts/draft-ietf-pkix-sim-07.txt</a><o:p></o:p></sp=
an></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Past IETF last =
Call.
A new draft is requested by IESG.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp; 2.6 Additional Algorithms and =
Identifiers for
DSA and ECDSA (5 min.)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tim Polk =
(NIST)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecds=
a-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ec=
dsa-00.txt</a><o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A new -00 draft =
has
just been posted.<o:p></o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>3. Related Specifications &amp; Liaison =
Presentations<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Time allowing,
liaison presentations will be accommodated to ensure =
the<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PKIX WG is =
aware of
related specifications currently progressing =
as<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; individual =
drafts.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp; 3.1 Including the AIA extension in =
attribute
certificates (10 min)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; David Chadwick =
(<st1:place
w:st=3D"on"><st1:PlaceType w:st=3D"on">University</st1:PlaceType> of =
<st1:PlaceName
 =
w:st=3D"on">Kent</st1:PlaceName></st1:place>)<o:p></o:p></span></font></p=
>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A presentation =
about
including the AIA extension in attribute certificates, =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and the =
requirement
to find the superior AA of the AC issuer, as well as the =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; signing =
certificate
of the issuer of the AC<o:p></o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>4. Joint PKIX/SIDR =
Meeting<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp; <a
href=3D"http://ietf.org/html.charters/sidr-charter.html">http://ietf.org/=
html.charters/sidr-charter.html</a><o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;4.1 Address Space &amp; As Number =
PKI
(60 min.)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stephen Kent =
(BBN)<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This =
presentation will
review the current plans and status for creating a =
PKI<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp; &nbsp;that reflects the
allocation of resources through Regional Internet =
Registries.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp; &nbsp;The motivation for =
creation
this PKI is to enable better security for =
Internet<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>&nbsp;&nbsp;&nbsp; &nbsp;routing =
(BGP).<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'><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'><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'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C69464.4267ACF2--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5K8k5pS099958; Tue, 20 Jun 2006 01:46:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5K8k5rT099957; Tue, 20 Jun 2006 01:46:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from srv1.int.stroeder.com (60-17-124-83.dsl.3u.net [83.124.17.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5K8k3F2099927 for <[e-mail]>; Tue, 20 Jun 2006 01:46:04 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id D3F6C4166 for <[e-mail]>; Tue, 20 Jun 2006 10:45:56 +0200 (CEST)
Received: from srv1.int.stroeder.com ([127.0.0.1]) by localhost (srv1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27429-08 for <[e-mail]>; Tue, 20 Jun 2006 10:44:31 +0200 (CEST)
Received: from [10.1.1.5] (unknown [10.1.1.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by srv1.int.stroeder.com (Postfix) with ESMTP id B45734163 for <[e-mail]>; Tue, 20 Jun 2006 10:44:30 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 20 Jun 2006 10:44:27 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new at int.stroeder.com
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>

Reference to RFC 2253 should be updated since it
was obsoleted by RFC 4514 recently.

Ciao, Michael.

[e-mail] wrote:
> 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 Certificate and Certificate Revocation List (CRL) Profile
> 	Author(s)	: D. Cooper, et al.
> 	Filename	: draft-ietf-pkix-rfc3280bis-03.txt
> 	Pages		: 141
> 	Date		: 2006-5-24



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JNBWkZ089463; Mon, 19 Jun 2006 16:11:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JNBWCZ089462; Mon, 19 Jun 2006 16:11:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k5JNBVaj089447 for <[e-mail]>; Mon, 19 Jun 2006 16:11:31 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 10786 invoked from network); 19 Jun 2006 23:11:26 -0000
Received: from unknown (HELO Wylie) ([e-mail]@70.17.105.223 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 19 Jun 2006 23:11:25 -0000
Reply-To: <[e-mail]>
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt 
Date: Mon, 19 Jun 2006 19:10:58 -0400
Organization: IECA, Inc.
Message-ID: <003401c693f5$a0039de0$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Thread-Index: AcaT4IUABkN6z3lrQc+Oiw9MAORuagADOfjA
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>

A couple of comments:

General: What is the relationship of this and the ECC PKALGS ID? Is the text
that is common going to be removed? Is the other ID dead (it has expired but
it's not clear that it won't be resurrected)? Is another draft being
prepared for the Key Agreement Schemes? 

Keys/Parameters: The document only addresses the
signatureAlgorithm/signatureVale/signature fields and points to RFC3279 for
the ECDSA Public Key Encodings...but it seems like there ought to be an
explicit indication of the algorithm the key can be used with in the
subjectPublicKeyInfo field along with its parameters? They do this with
DSA/RSA why not with ECDSA?

Specific
Sec 3 1st para last sentence: r field/fields
Sec 3 4th para last sentence: r should/SHOULD
Sec 3.1 1st para 2nd sentence r SHA2/SHA-2
Sec 3.2 bullets 1, 2, 3: r may/MAY
Sec 3.2.1 1st para: r SHA 512/SHA512

spt
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Monday, June 19, 2006 3:50 PM
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt 

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: 
                          Additional Algorithms and Identifiers for DSA and
ECDSA  
	Author(s)	: Q. Dang, et al.
	Filename	: draft-ietf-pkix-sha2-dsa-ecdsa-00.txt
	Pages		: 
	Date		: 2006-6-19
	
        This document supplements RFC 3279. It 
        specifies algorithm identifiers, and ASN.1 
        encoding rules for the Digital Signature 
        Algorithm (DSA) and Elliptic Curve Digital 
        Signature Algorithm (ECDSA) digital signatures 
        when using SHA-224, SHA-256, 384 or SHA-512 as 
        hashing algorithm. This specification applies 
        to the Internet X.509 Public Key 
        Infrastructure (PKI) when digital signatures 
        are used to sign certificates and certificate 
        revocation list (CRLs).  

        The key words "MUST", "MUST NOT", "REQUIRED", 
        "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
        "RECOMMENDED", "MAY", and "OPTIONAL" in this 
        document are to be interpreted as described in 
        [RFC 2119]. 


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.txt

To remove yourself from the I-D Announcement list, send a message to
[e-mail] with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


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-sha2-dsa-ecdsa-00.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-sha2-dsa-ecdsa-00.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.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JKnFKT060472; Mon, 19 Jun 2006 13:49:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JKnFAu060471; Mon, 19 Jun 2006 13:49:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (host200.58.41.216.conversent.net [216.41.58.200]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JKnELS060441 for <[e-mail]>; Mon, 19 Jun 2006 13:49:14 -0700 (MST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt 
Date: Mon, 19 Jun 2006 16:49:07 -0400
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03AF_01C693C0.47A81700"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt 
Thread-Index: AcaT26+2MLXK1X5zRxO2IesgECCEswABbr5A
From: "Seth Hitchings" <[e-mail]>
To: <[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>

This is a multi-part message in MIME format.

------=_NextPart_000_03AF_01C693C0.47A81700
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Section 3.1 (DSA Signature Algorithm) lists both id-dsa-with-sha224 and
id-dsa-with-sha256 as:

joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3) algorithms(4) id-dsa-with-sha2(3) 1

They're correctly identified (I think) in the ASN.1 module as 3.1 and 3.2,
respectively.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of [e-mail]
Sent: Monday, June 19, 2006 3:50 PM
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt 

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: 
                          Additional Algorithms and Identifiers for DSA and
ECDSA  
	Author(s)	: Q. Dang, et al.
	Filename	: draft-ietf-pkix-sha2-dsa-ecdsa-00.txt
	Pages		: 
	Date		: 2006-6-19
	
        This document supplements RFC 3279. It 
        specifies algorithm identifiers, and ASN.1 
        encoding rules for the Digital Signature 
        Algorithm (DSA) and Elliptic Curve Digital 
        Signature Algorithm (ECDSA) digital signatures 
        when using SHA-224, SHA-256, 384 or SHA-512 as 
        hashing algorithm. This specification applies 
        to the Internet X.509 Public Key 
        Infrastructure (PKI) when digital signatures 
        are used to sign certificates and certificate 
        revocation list (CRLs).  

        The key words "MUST", "MUST NOT", "REQUIRED", 
        "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
        "RECOMMENDED", "MAY", and "OPTIONAL" in this 
        document are to be interpreted as described in 
        [RFC 2119]. 


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.txt

To remove yourself from the I-D Announcement list, send a message to
[e-mail] with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


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-sha2-dsa-ecdsa-00.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-sha2-dsa-ecdsa-00.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_000_03AF_01C693C0.47A81700
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIVzCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCAw0wggJ2oAMCAQICAXwwDQYJKoZI
hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE
AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDUwODI5MTQyNTQwWhcNMDYw
OTEyMTQyNTQwWjBqMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRcwFQYD
VQQDEw5TZXRoIEhpdGNoaW5nczEoMCYGCSqGSIb3DQEJARYZc2hpdGNoaW5nc0Bjb3Jlc3RyZWV0
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzZOhlCd/KDWl33RR6dW+YKFd8Kof1Uz8
9wJ3EevLEK73npZfKDj66mL6fQOL1Cv1RaQrucsm8ZB2bMvUDRvoeC1Te4xsHvxNyV8AoEbxYWsK
QciJCNM5bd6kkpfgummUBCgUs7nze+FNhIzWGerlMUjcc37diSOD+FP24WXU+zUCAwEAAaOB2jCB
1zAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5nZW90cnVzdC5j
b20vY3Jscy9jb3Jlc3RyZWV0LmNybDAkBgNVHREEHTAbgRlzaGl0Y2hpbmdzQGNvcmVzdHJlZXQu
Y29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAGCCsGAQUFBwEBBDQwMjAwBggr
BgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0cmVldC5jb20vMA0GCSqGSIb3DQEB
BQUAA4GBAHPT6HnJxaWD8+WdUL//eXEekqR0rio7r2OdTJ4VSrWZQRHMkWmOzG8aPvgGX7SMh0QZ
TvcSBNY7h43m5fPNk7Jaxy+F3LbdwHu02NM/IiUBsLyn8XXi03Xekni5PT6aDuP/Egux3nnlKjej
mMjDOVTNBwKwF/QfjP+QViQTO6hoMYICmTCCApUCAQEwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UE
ChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhv
cml0eQIBfDAJBgUrDgMCGgUAoIIBmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wNjA2MTkyMDQ5MDdaMCMGCSqGSIb3DQEJBDEWBBTFSBrGrSbb7ZipPU03Yc9KG39m
ZjBmBgkrBgEEAYI3EAQxWTBXMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0
ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgF8MGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCyqGSIb3DQEJEAILMVmg
VzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3Jl
U3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBfDANBgkqhkiG9w0BAQEFAASBgG8HPFCgVDNY
rbDTRiwM90zZSSHPqapmTpKHK2bY7bfA0ZEF7ZJ7eM0jq/EGfYqy754xQrK92hvsUGdFvKVQjoZB
c699cXA/LyOqJ9/XlPWQT6MJCn3wp0tYNf9qstF1m9Dvq1tOu9hkqbmXMuE7m5V6hHCeG1oM2Qb8
jIX9aMRXAAAAAAAA

------=_NextPart_000_03AF_01C693C0.47A81700--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JJoBBr048015; Mon, 19 Jun 2006 12:50:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JJoBIO048014; Mon, 19 Jun 2006 12:50:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JJoA5J047974 for <[e-mail]>; Mon, 19 Jun 2006 12:50:11 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo2Hp007634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jun 2006 19:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl4-0007Zm-3w; Mon, 19 Jun 2006 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sha2-dsa-ecdsa-00.txt 
Message-Id: <[e-mail]>
Date: Mon, 19 Jun 2006 15:50:02 -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: 
                          Additional Algorithms and Identifiers for DSA and ECDSA  
	Author(s)	: Q. Dang, et al.
	Filename	: draft-ietf-pkix-sha2-dsa-ecdsa-00.txt
	Pages		: 
	Date		: 2006-6-19
	
        This document supplements RFC 3279. It 
        specifies algorithm identifiers, and ASN.1 
        encoding rules for the Digital Signature 
        Algorithm (DSA) and Elliptic Curve Digital 
        Signature Algorithm (ECDSA) digital signatures 
        when using SHA-224, SHA-256, 384 or SHA-512 as 
        hashing algorithm. This specification applies 
        to the Internet X.509 Public Key 
        Infrastructure (PKI) when digital signatures 
        are used to sign certificates and certificate 
        revocation list (CRLs).  

        The key words "MUST", "MUST NOT", "REQUIRED", 
        "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
        "RECOMMENDED", "MAY", and "OPTIONAL" in this 
        document are to be interpreted as described in 
        [RFC 2119]. 


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha2-dsa-ecdsa-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-sha2-dsa-ecdsa-00.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-sha2-dsa-ecdsa-00.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-sha2-dsa-ecdsa-00.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JJo9En047998; Mon, 19 Jun 2006 12:50:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JJo9jU047997; Mon, 19 Jun 2006 12:50:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JJo8ia047973 for <[e-mail]>; Mon, 19 Jun 2006 12:50:08 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo2WR003167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jun 2006 19:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl3-0007ZO-V3; Mon, 19 Jun 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-26.txt 
Message-Id: <[e-mail]>
Date: Mon, 19 Jun 2006 15:50:01 -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		: Server-based Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-26.txt
	Pages		: 84
	Date		: 2006-6-19
	
SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server.  The path construction or
   validation (e.g. making sure that none of the certificates in the
   path are revoked) is performed according to a validation policy,
   which contains one or more trust anchors.  It allows simplification
   of client implementations and use of a set of predefined validation
   policies.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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-scvp-26.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-scvp-26.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-scvp-26.txt

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

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

--OtherAccess--

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JCvXCa067152; Mon, 19 Jun 2006 05:57:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5JCvXrX067151; Mon, 19 Jun 2006 05:57:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5JCvWQl067144 for <[e-mail]>; Mon, 19 Jun 2006 05:57:32 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.192.42.43]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1FsJJm-0008Bo-3O for [e-mail]; Mon, 19 Jun 2006 08:57:26 -0400
Mime-Version: 1.0
Message-Id: <p06230900c0bbf403f460@[128.89.89.106]>
Date: Mon, 19 Jun 2006 02:27:46 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: slight whoops
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>

As you may have noticed, Stefan and I independently sent out last 
call notices for 3820bis, with slightly different closing dates.  We 
have agreed to go with my date, so July 5th is the close of last call 
for 3280bis.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GKgf0e086321; Fri, 16 Jun 2006 13:42:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GKgfwq086320; Fri, 16 Jun 2006 13:42:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GKge9K086292 for <[e-mail]>; Fri, 16 Jun 2006 13:42:41 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.136.89]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1FrL9G-0008Sj-5H for [e-mail]; Fri, 16 Jun 2006 16:42:34 -0400
Mime-Version: 1.0
Message-Id: <p06230906c0b8c72ccc06@[128.89.89.106]>
Date: Fri, 16 Jun 2006 16:42:28 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: last call for 3280bis
Content-Type: multipart/alternative; boundary="============_-1061631940==_ma============"
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>

--============_-1061631940==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Folks,

Based on the latest message from David Cooper, I am initiating last 
call on "Internet X.509 Public Key Infrastructure, Certificate and 
Certificate Revocation List (CRL) Profile" 
(<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt>http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt)

The last call will last for two weeks. In deference to the U.S. 
Independence Dya holiday (which means July 3rd is a holiday for many 
folks), all comments must be received by July 5th.

Steve
--============_-1061631940==_ma============
Content-Type: text/html; charset="us-ascii"

<!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>last call for 3280bis</title></head><body>
<div>Folks,</div>
<div><br></div>
<div>Based on the latest message from David Cooper, I am initiating
last call on<font size="-1"> &quot;Internet X.509 Public Key
Infrastructure, Certificate and Certificate Revocation List (CRL)
Profile"</font><tt> (</tt><a
href=
"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt"><font
 size="-1"
>http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt</font
></a><font size="-1">)</font></div>
<div><font size="-1">&nbsp;</font></div>
<div><font size="-1">The last call will last for two weeks. In
deference to the U.S. Independence Dya holiday (which means July 3rd
is a holiday for many folks), all comments must be received by July
5th.</font></div>
<div><font size="-1"><br></font></div>
<div><font size="-1">Steve</font></div>
</body>
</html>
--============_-1061631940==_ma============--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GJcbOv069992; Fri, 16 Jun 2006 12:38:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GJcbdD069991; Fri, 16 Jun 2006 12:38:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GJcaRN069976 for <[e-mail]>; Fri, 16 Jun 2006 12:38:37 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5GJcWBo019756 for <[e-mail]>; Fri, 16 Jun 2006 15:38:32 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5GJbiOB028565 for <[e-mail]>; Fri, 16 Jun 2006 15:37:44 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 16 Jun 2006 15:38:04 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: draft-ietf-pkix-scvp-26.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [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>

All,

I have just submitted draft 26 of SCVP for posting.  The draft should be 
available soon, but in the meantime, I have posted a diff file 
highlighting the differences between drafts 24 and 26 (the only 
difference between drafts 24 and 25 was the correction of a 
typographical error in section 3.6).  The diff file is available at 
http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-24_to_26.html.

Drafts 24 and 26 differ in the following places:

1) Section 3: corrected cross-reference ("3.10" replaced by "3.11").

2) Section 3.2.4.2.3 (Name Validation Algorithm):  Matching rules for 
use with id-kp-serverAuth are now specified in the document rather than 
referring to the matching rules in RFC 2818 [HTTP-TLS].  (RFC 2818 is an 
Informational RFC and so SCVP could not include a normative reference to 
that document).

3) Section 3.6: "requestorName" replaced with "responderName".  (This 
was the typographical error that was corrected in draft 25.)

4) Section 4: A new sentence was added to clarify that when a protected 
response is required, the SCVP server must use SignedData or 
AuthenticatedData even if the response is being sent over a protected 
transport (e.g., TLS).

5) Section 11.1 (Normative References):  The reference to RFC 2818 was 
deleted.


None of these changes to the document result in any changes to the protocol.


Dave



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GHdun2040251; Fri, 16 Jun 2006 10:39:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GHdug5040250; Fri, 16 Jun 2006 10:39:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GHdsu8040236 for <[e-mail]>; Fri, 16 Jun 2006 10:39:55 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 18:39:53 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6916B.E03064F2"
Subject: WG Last Call: RFC3280bis
Date: Fri, 16 Jun 2006 18:39:52 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WG Last Call: RFC3280bis
thread-index: AcaRa9/PSg6uKi45SZ+HHXAxZPazQA==
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 16 Jun 2006 17:39:53.0711 (UTC) FILETIME=[E049F7F0:01C6916B]
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_001_01C6916B.E03064F2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Folks,

=20

This message initiates working group last call for "Internet X.509
Public Key Infrastructure, Certificate and Certificate Revocation List
(CRL) Profile"

This document is currently available at:
http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt. =20

=20

The last call will be two weeks.  That is, Last Call for this document
closes on or after July 3rd, 2006.

=20

Since I'm co-editor, Steve Kent will determine WG consensus.

=20

Thanks,

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20


------_=_NextPart_001_01C6916B.E03064F2
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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Folks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>This message initiates working group last =
call for &quot;Internet X.509 Public Key Infrastructure, Certificate and =
Certificate Revocation List (CRL) =
Profile&#8221;<o:p></o:p></span></font></pre>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>This document is =
currently
available at: <a
href=3D"http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt=
">http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt</a>.&=
nbsp;
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>The last call will =
be two
weeks.&nbsp; That is, Last Call for this document closes on or after =
July 3rd,
2006.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier New"'>Since I&#8217;m =
co-editor,
Steve Kent will determine WG consensus.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><o:p></o:p></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6916B.E03064F2--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GH8jtq032776; Fri, 16 Jun 2006 10:08:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GH8jLf032775; Fri, 16 Jun 2006 10:08:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GH8hdc032768 for <[e-mail]>; Fri, 16 Jun 2006 10:08:44 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k5GH8U3X009701; Fri, 16 Jun 2006 13:08:31 -0400
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.6/8.13.6) with ESMTP id k5GH8BOM021775; Fri, 16 Jun 2006 13:08:11 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Fri, 16 Jun 2006 13:08:30 -0400
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: pkix <[e-mail]>
Subject: Re: [Fwd: draft-ietf-pkix-scvp-25.txt]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: [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>

This was a typographical error.  The text should have referred to 
section 3.11 (SCVP Request Authentication), which defines the 
id-kp-scvpClient OID, but the cross-reference did not get updated when a 
new subsection was added to section 3.

yannick quenechdu wrote:

>Hi,
>
>I would wish a clarification about section 3 :
>
>"If the extended key usage extension is present, it MUST contain either
>the SCVP client OID (see Section 3.10) or another OID acceptable to the
>SCVP server."
>
>I do not see the relation with section 3.10. It is necessary to use the
>field RequestorText to indicate a OID for SCVP client ?
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GBlNGR064551; Fri, 16 Jun 2006 04:47:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5GBlNG8064550; Fri, 16 Jun 2006 04:47:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GBlMUB064530 for <[e-mail]>; Fri, 16 Jun 2006 04:47:22 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 12:47:15 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6913A.9D1E621C"
Subject: RE: Request for agenda items for next IETF in Montreal
Date: Fri, 16 Jun 2006 12:47:15 +0100
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Request for agenda items for next IETF in Montreal
thread-index: AcaGi5FVe42aNExIS2mEBuVUe7WsrQKrr3DA
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 16 Jun 2006 11:47:15.0913 (UTC) FILETIME=[9D423390:01C6913A]
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_001_01C6913A.9D1E621C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I would appreciate if editors of each wg document could send me a note
about whether any of the editors will be at the PKIX meeting and how
much time they need to make a status report.

=20

Thanks

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: den 2 juni 2006 23:29
To: [e-mail]
Subject: Request for agenda items for next IETF in Montreal

=20

At next IETF in Montreal we are going to have two PKIX sessions.

=20

One PKIX only session, in the traditional form, and one joint session
with the SIDR WG (Secure Inter-Domain Routing)

At the joint PKIX/SIDR meeting, Steve Kent will give a 1 hour
presentation on a PKI proposal.

=20

I will however only manage the agenda for the PKIX only session.

=20

Please let me know if you want to request a time slot for this meeting.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20


------_=_NextPart_001_01C6913A.9D1E621C
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
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=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I would appreciate if editors of =
each wg
document could send me a note about whether any of the editors will be =
at the
PKIX meeting and how much time they need to make a status =
report.<o:p></o:p></span></font></p>

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

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

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

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><font
color=3Dnavy><span style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

</div>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 2 juni 2006 =
23:29<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Request for =
agenda items
for next IETF in <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Montreal</st1:place></st1:City></span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><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'>At next IETF in <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Montreal</st1:City></st1:place>
we are going to have two PKIX sessions.<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'>One PKIX only session, in the traditional form, and =
one
joint session with the SIDR WG (</span></font>Secure Inter-Domain =
Routing<font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>)<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'>At the joint PKIX/SIDR meeting, Steve Kent will give =
a 1
hour presentation on a PKI proposal.<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'>I will however only manage the agenda for the PKIX =
only session.<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'>Please let me know if you want to request a time slot =
for
this meeting.<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><o:p></o:p></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6913A.9D1E621C--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5FEDPf0085845; Thu, 15 Jun 2006 07:13:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5FEDPWe085844; Thu, 15 Jun 2006 07:13:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5FEDOQX085803 for <[e-mail]>; Thu, 15 Jun 2006 07:13:25 -0700 (MST) (envelope-from [e-mail])
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5FEDIRx004082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Jun 2006 14:13:18 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fqsb0-0006sq-0Y; Thu, 15 Jun 2006 10:13:18 -0400
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: 'Lightweight OCSP Profile for High Volume Environments' to  Informational RFC (draft-ietf-pkix-lightweight-ocsp-profile) 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 15 Jun 2006 10:13:18 -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>

The IESG has received a request from the Public-Key Infrastructure (X.509) WG 
to consider the following document:

- 'Lightweight OCSP Profile for High Volume Environments '
   <draft-ietf-pkix-lightweight-ocsp-profile-05.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2006-06-29.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile-05.txt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k52LT6BS029392; Fri, 2 Jun 2006 14:29:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k52LT6wW029391; Fri, 2 Jun 2006 14:29:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k52LT4hd029384 for <[e-mail]>; Fri, 2 Jun 2006 14:29:05 -0700 (MST) (envelope-from [e-mail])
Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 22:29:03 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6868B.922D5A85"
Subject: Request for agenda items for next IETF in Montreal
Date: Fri, 2 Jun 2006 22:29:02 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Request for agenda items for next IETF in Montreal
Thread-Index: AcaGi5FVe42aNExIS2mEBuVUe7WsrQ==
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 02 Jun 2006 21:29:03.0526 (UTC) FILETIME=[9208BC60:01C6868B]
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_001_01C6868B.922D5A85
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

At next IETF in Montreal we are going to have two PKIX sessions.

=20

One PKIX only session, in the traditional form, and one joint session
with the SIDR WG (Secure Inter-Domain Routing)

At the joint PKIX/SIDR meeting, Steve Kent will give a 1 hour
presentation on a PKI proposal.

=20

I will however only manage the agenda for the PKIX only session.

=20

Please let me know if you want to request a time slot for this meeting.

=20

=20

Stefan Santesson

Senior Program Manager

Windows Security, Standards

=20


------_=_NextPart_001_01C6868B.922D5A85
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>At next IETF in <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Montreal</st1:City></st1:place>
we are going to have two PKIX sessions.<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'>One PKIX only session, in the traditional form, and =
one
joint session with the SIDR WG (</span></font>Secure Inter-Domain =
Routing<font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>)<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'>At the joint PKIX/SIDR meeting, Steve Kent will give =
a 1
hour presentation on a PKI proposal.<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'>I will however only manage the agenda for the PKIX =
only session.<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'>Please let me know if you want to request a time slot =
for
this meeting.<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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dmaroon =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:maroon'>Stefan =
Santesson</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#400040" face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Senior =
Program Manager</span></font><o:p></o:p></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3D"#400040" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#400040'>Windows =
Security,
Standards</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C6868B.922D5A85--