From d.w.chadwick@kent.ac.uk Wed Aug 1 04:26:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C732121F86A1 for ; Wed, 1 Aug 2012 04:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.149 X-Spam-Level: X-Spam-Status: No, score=-7.149 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqsuyolDanEw for ; Wed, 1 Aug 2012 04:26:40 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 74AF421F8608 for ; Wed, 1 Aug 2012 04:26:39 -0700 (PDT) Received: from mx0.kent.ac.uk ([129.12.21.32]) by mx1.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwX4T-00053W-OH; Wed, 01 Aug 2012 12:26:33 +0100 Received: from [146.90.53.149] (helo=[192.168.1.39]) by mx0.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwX4T-0001DM-0V; Wed, 01 Aug 2012 12:26:33 +0100 Message-ID: <50191269.8090000@kent.ac.uk> Date: Wed, 01 Aug 2012 12:26:33 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Patrick Patterson References: <501847DC.5030509@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 11:26:41 -0000 Hi Patrick one problem see with this is as follows The RP typically gives a binary blob to the PKI and asks it to validate the signature on the binary blob. The PKI has no knowledge about the semantic content of this blob. So it cannot tell the difference between a SAML assertion, OpenID assertion, Oauth assertion, Word document, or a love letter. I dont think we should be building this sort of semantics into signature verification. regards David On 01/08/2012 03:11, Patrick Patterson wrote: > Hi Sean, > > We're currently working the definition of "claim" that we're going to use and have come up with: > > "A signed claim is a set of attributes bound to a particular subject using a digital signature in a way that relying parties can make access or authorization decisions. > > The presence of the claimSigning EKU indicates that a CA has approved the certificate holder to sign claims for use within a specific community of interest (e.g., a Federation) according to the rules of that community. In other words, the holder of a certificate that asserts the claimSigning EKU can bind attributes to a subject for processing by a relying party " > > What do people think about that? > > We'll be further augmenting this definition with clearer examples, but the original one for use by an IDP is still my main target (Matt has his own which will be made clear in the updated draft :). We'll also be addressing a bit why the current status quo may not work for everyone (and may not continue to work for anyone if all certificates issued by major CAs that assert digSig and nonRep start having mandatory populated EKU values). > > I'll talk to Stefan tomorrow, but I'm leaning towards withdrawing our spot on the Agenda tomorrow, until we can come up with a Draft that addresses the concerns posted. (There's also the matter that Matt's not here, and I've got to leave before PKIX tomorrow :( ) > > Cheers, > > Patrick. > > On 2012-07-31, at 5:02 PM, Sean Turner wrote: > >> I'm confused how a vague definition of a claim lines up with the need for a specific EKU (from Patrick's earlier message): >> >> Unfortunately, due to recent events regarding the abuse >> of certificates asserting Key Usage values of >> digitalSignature and nonRepudiation, a number of policy >> authorities are mandating strict EKU values in all >> certificates asserting these key usage values, and >> mandating by policy that the anyEKU OID not be present. >> >> You need a specific EKU to indicate you can sign a nebulous thing. What's the client going to check to know whether it's signing a claim or not? >> >> spt >> >> On 7/31/12 10:55 AM, Stefan Santesson wrote: >>> David, >>> >>> A broad definition of "Claim" may be appropriate, but there need to be one. >>> Absent a definition, the EKU becomes somewhat pointless as usage >>> declaration. >>> >>> /Stefan >>> >>> >>> >>> >>> On 12-07-31 10:37 AM, "David A. Cooper" wrote: >>> >>>> Stefan, >>>> >>>> Based on earlier discussions that I've had with some of the editors of >>>> this document, I believe that the reason the draft isn't entirely clear >>>> about what might constitute a "Claim" is that there is a desire for the >>>> definition of this OID to be somewhat generic so that in the future, >>>> when a key purpose OID is needed to indicate that the subject is >>>> authorized to sign "claims," this OID can be used rather than having to >>>> define a new OID for each specific application. >>>> >>>> As an example, there are some signed CMS objects on PIV Cards. The CMS >>>> objects contain such things as biometric data of the cardholder and/or a >>>> unique identifier that has been assigned to the card. In FIPS 201, a >>>> key purpose OID was defined, id-PIV-content-signing, and there is a >>>> requirement that the signer of the CMS objects on the PIV Card must have >>>> a certificate that asserts the id-PIV-content-signing key purpose OID. >>>> When PIV-Interoperable cards were defined (similar to PIV Cards, but not >>>> issued by the U.S. Federal government), a new key purpose OID needed to >>>> be defined for the signers of the CMS objects on those cards, >>>> id-fpki-pivi-content-signing. It was noted that if there were a generic >>>> "claim signing" OID, then that OID could be used for both PIV and PIV-I >>>> Cards in addition to other cards that don't qualify as either PIV or >>>> PIV-I. We even received a comment on the current draft of FIPS 201 >>>> (http://csrc.nist.gov/publications/drafts/fips201-2/draft-fips-201-2_comme >>>> nts_disposition-for-2011-draft.pdf) >>>> asking that FIPS 201 specify the use of the claimSigning OID being >>>> discussed in the PKIX WG rather than (or in addition to) the >>>> id-PIV-content-signing OID. >>>> >>>> Dave >>>> >>>> On 07/30/2012 03:04 PM, Stefan Santesson wrote: >>>>> I have a number of issues/questions regarding this draft (still). >>>>> >>>>> 1) Definition of "Claim" >>>>> This EKU is said to state that the subject is appropriate to sign >>>>> "claims", but the draft does not make an effort to define what a claim >>>>> is. >>>>> It provides the examples SAML assertions and Attribute Assertions, but >>>>> does not state what else could be regarded as a claim. >>>>> Thus this EKU could be used for virtually anything in absence of a clear >>>>> definition. >>>>> >>>>> 2) Explain when this EKU is needed, relative to metadata and >>>>> pre-configured trust. >>>>> The only examples are SAML. In SAML it is common to either preconfigure >>>>> trust in assertion signers, removing the need for an EKU, or by placing >>>>> the cert in signed metadata also removing the need for an EKU. What are >>>>> the particular use-case where you would neither use metadata, nor >>>>> pre-configured trust? >>>>> A clarification of this would help the reader to understand when this >>>>> EKU >>>>> is appropriate. >>>>> >>>>> 3) Discussion about assurance levels and policy OIDs. >>>>> When would you convey information about assurance level of an assertion >>>>> in >>>>> a certificate policy of the signing certificate? >>>>> Information about assurance level is provided in SAML requests and >>>>> responses. >>>>> Information about what assurance level the IdP is trusted to provide >>>>> (certified for) is normally provided in signed metadata (SAML) or may be >>>>> implicit in the case of pre-configured trust. >>>>> When would it be appropriate to solve this using cert policies? >>>>> Is there any deployed examples of this? >>>>> >>>>> >>>>> /Stefan >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > --- > Patrick Patterson > President and Chief PKI Architect > Carillon Information Security Inc. > http://www.carillon.ca > > tel: +1 514 485 0789 > mobile: +1 514 994 8699 > fax: +1 450 424 9559 > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From ppatterson@carillon.ca Wed Aug 1 06:47:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A105921F86EF for ; Wed, 1 Aug 2012 06:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGIswADPhlu8 for ; Wed, 1 Aug 2012 06:47:19 -0700 (PDT) Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.18]) by ietfa.amsl.com (Postfix) with ESMTP id 71FCB21F8648 for ; Wed, 1 Aug 2012 06:47:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id 5D1CDA80758; Wed, 1 Aug 2012 09:47:27 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at rhea-new.carillon.ca Received: from mail.carillon.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHIlQhxU6Xoo; Wed, 1 Aug 2012 09:47:25 -0400 (EDT) Received: from [101.132.166.27] (S01060012cfcb89fa.vc.shawcable.net [174.6.162.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTPSA id 0E346A8064E; Wed, 1 Aug 2012 09:47:23 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Patrick Patterson In-Reply-To: <50191269.8090000@kent.ac.uk> Date: Wed, 1 Aug 2012 09:47:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5E5299BC-836C-4BD3-A0EA-904B5EF3D8E2@carillon.ca> References: <501847DC.5030509@ieca.com> <50191269.8090000@kent.ac.uk> To: David Chadwick X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 13:47:20 -0000 Hi David, I'm not at all sure what you are talking about - I've never seen a world = where an RP gives anything to the PKI to verify - it usually (when it is = well behaved) extracts the certificate (after making sure that the = public key in the cert is the same that was used to sign the message) = and does RFC5280 Section 6 validation on it, or at least makes sure this = Certificate chains to a Trust Anchor that it has pre-configured. This is = all done on the RP itself. The RP knows the semantics of the message = that it has, and presumably (in the case of SAML) knows who the = authorised IDPs are (which may include, in this case, checking to see if = the claimSigning EKU is present). I'm not asking for, or saying anything about signature semantics - = Stefan and Sean wanted a definition of a claim to be used when asserting = the "claimSigning" EKU, and I gave it to them. Cheers, Patrick. On 2012-08-01, at 7:26 AM, David Chadwick wrote: > Hi Patrick >=20 > one problem see with this is as follows >=20 > The RP typically gives a binary blob to the PKI and asks it to = validate the signature on the binary blob. The PKI has no knowledge = about the semantic content of this blob. So it cannot tell the = difference between a SAML assertion, OpenID assertion, Oauth assertion, = Word document, or a love letter. >=20 > I dont think we should be building this sort of semantics into = signature verification. >=20 > regards >=20 > David >=20 >=20 > On 01/08/2012 03:11, Patrick Patterson wrote: >> Hi Sean, >>=20 >> We're currently working the definition of "claim" that we're going to = use and have come up with: >>=20 >> "A signed claim is a set of attributes bound to a particular subject = using a digital signature in a way that relying parties can make access = or authorization decisions. >>=20 >> The presence of the claimSigning EKU indicates that a CA has approved = the certificate holder to sign claims for use within a specific = community of interest (e.g., a Federation) according to the rules of = that community. In other words, the holder of a certificate that asserts = the claimSigning EKU can bind attributes to a subject for processing by = a relying party " >>=20 >> What do people think about that? >>=20 >> We'll be further augmenting this definition with clearer examples, = but the original one for use by an IDP is still my main target (Matt has = his own which will be made clear in the updated draft :). We'll also be = addressing a bit why the current status quo may not work for everyone = (and may not continue to work for anyone if all certificates issued by = major CAs that assert digSig and nonRep start having mandatory populated = EKU values). >>=20 >> I'll talk to Stefan tomorrow, but I'm leaning towards withdrawing our = spot on the Agenda tomorrow, until we can come up with a Draft that = addresses the concerns posted. (There's also the matter that Matt's not = here, and I've got to leave before PKIX tomorrow :( ) >>=20 >> Cheers, >>=20 >> Patrick. >>=20 >> On 2012-07-31, at 5:02 PM, Sean Turner wrote: >>=20 >>> I'm confused how a vague definition of a claim lines up with the = need for a specific EKU (from Patrick's earlier message): >>>=20 >>> Unfortunately, due to recent events regarding the abuse >>> of certificates asserting Key Usage values of >>> digitalSignature and nonRepudiation, a number of policy >>> authorities are mandating strict EKU values in all >>> certificates asserting these key usage values, and >>> mandating by policy that the anyEKU OID not be present. >>>=20 >>> You need a specific EKU to indicate you can sign a nebulous thing. = What's the client going to check to know whether it's signing a claim or = not? >>>=20 >>> spt >>>=20 >>> On 7/31/12 10:55 AM, Stefan Santesson wrote: >>>> David, >>>>=20 >>>> A broad definition of "Claim" may be appropriate, but there need to = be one. >>>> Absent a definition, the EKU becomes somewhat pointless as usage >>>> declaration. >>>>=20 >>>> /Stefan >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 12-07-31 10:37 AM, "David A. Cooper" = wrote: >>>>=20 >>>>> Stefan, >>>>>=20 >>>>> Based on earlier discussions that I've had with some of the = editors of >>>>> this document, I believe that the reason the draft isn't entirely = clear >>>>> about what might constitute a "Claim" is that there is a desire = for the >>>>> definition of this OID to be somewhat generic so that in the = future, >>>>> when a key purpose OID is needed to indicate that the subject is >>>>> authorized to sign "claims," this OID can be used rather than = having to >>>>> define a new OID for each specific application. >>>>>=20 >>>>> As an example, there are some signed CMS objects on PIV Cards. The = CMS >>>>> objects contain such things as biometric data of the cardholder = and/or a >>>>> unique identifier that has been assigned to the card. In FIPS = 201, a >>>>> key purpose OID was defined, id-PIV-content-signing, and there is = a >>>>> requirement that the signer of the CMS objects on the PIV Card = must have >>>>> a certificate that asserts the id-PIV-content-signing key purpose = OID. >>>>> When PIV-Interoperable cards were defined (similar to PIV Cards, = but not >>>>> issued by the U.S. Federal government), a new key purpose OID = needed to >>>>> be defined for the signers of the CMS objects on those cards, >>>>> id-fpki-pivi-content-signing. It was noted that if there were a = generic >>>>> "claim signing" OID, then that OID could be used for both PIV and = PIV-I >>>>> Cards in addition to other cards that don't qualify as either PIV = or >>>>> PIV-I. We even received a comment on the current draft of FIPS = 201 >>>>> = (http://csrc.nist.gov/publications/drafts/fips201-2/draft-fips-201-2_comme= >>>>> nts_disposition-for-2011-draft.pdf) >>>>> asking that FIPS 201 specify the use of the claimSigning OID being >>>>> discussed in the PKIX WG rather than (or in addition to) the >>>>> id-PIV-content-signing OID. >>>>>=20 >>>>> Dave >>>>>=20 >>>>> On 07/30/2012 03:04 PM, Stefan Santesson wrote: >>>>>> I have a number of issues/questions regarding this draft (still). >>>>>>=20 >>>>>> 1) Definition of "Claim" >>>>>> This EKU is said to state that the subject is appropriate to sign >>>>>> "claims", but the draft does not make an effort to define what a = claim >>>>>> is. >>>>>> It provides the examples SAML assertions and Attribute = Assertions, but >>>>>> does not state what else could be regarded as a claim. >>>>>> Thus this EKU could be used for virtually anything in absence of = a clear >>>>>> definition. >>>>>>=20 >>>>>> 2) Explain when this EKU is needed, relative to metadata and >>>>>> pre-configured trust. >>>>>> The only examples are SAML. In SAML it is common to either = preconfigure >>>>>> trust in assertion signers, removing the need for an EKU, or by = placing >>>>>> the cert in signed metadata also removing the need for an EKU. = What are >>>>>> the particular use-case where you would neither use metadata, nor >>>>>> pre-configured trust? >>>>>> A clarification of this would help the reader to understand when = this >>>>>> EKU >>>>>> is appropriate. >>>>>>=20 >>>>>> 3) Discussion about assurance levels and policy OIDs. >>>>>> When would you convey information about assurance level of an = assertion >>>>>> in >>>>>> a certificate policy of the signing certificate? >>>>>> Information about assurance level is provided in SAML requests = and >>>>>> responses. >>>>>> Information about what assurance level the IdP is trusted to = provide >>>>>> (certified for) is normally provided in signed metadata (SAML) or = may be >>>>>> implicit in the case of pre-configured trust. >>>>>> When would it be appropriate to solve this using cert policies? >>>>>> Is there any deployed examples of this? >>>>>>=20 >>>>>>=20 >>>>>> /Stefan >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>=20 >> --- >> Patrick Patterson >> President and Chief PKI Architect >> Carillon Information Security Inc. >> http://www.carillon.ca >>=20 >> tel: +1 514 485 0789 >> mobile: +1 514 994 8699 >> fax: +1 450 424 9559 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 From david.cooper@nist.gov Wed Aug 1 06:56:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FA511E808D for ; Wed, 1 Aug 2012 06:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmq5j+OXgiU6 for ; Wed, 1 Aug 2012 06:56:27 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEAB11E80FD for ; Wed, 1 Aug 2012 06:56:27 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 1 Aug 2012 09:55:58 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Wed, 1 Aug 2012 09:55:06 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q71Du36e026316; Wed, 1 Aug 2012 09:56:03 -0400 Message-ID: <50193573.1090303@nist.gov> Date: Wed, 1 Aug 2012 09:56:03 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120723 Thunderbird/14.0 MIME-Version: 1.0 To: "mrex@sap.com" References: <20120801015310.9095A1A106@ld9781.wdf.sap.corp> In-Reply-To: <20120801015310.9095A1A106@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix Subject: Re: [pkix] 2560bis (essay version) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 13:56:28 -0000 Martin, Please read http://www.ietf.org/mail-archive/web/pkix/current/msg27687.html for an example of the confusion that the text in RFC 2560 is causing. This is not about making changes to the protocol and then trying to achieve greater adoption of those changes, it is about making the document sufficiently clear and unambiguous that problems like the one described in that message can be avoided in the future. In this message, you are again asking for changes to be made. For example you said: > What seems to be badly lacking in Appendix E of -04 is the requirements > of which certs MUST be included in the OCSP response for each of the > example CA/OCSP architecture/hierarchy, except for Figure 1 (where > no cert is necessary). I was given a very strict mandate to not make any changes to OCSP. Can you show me where this "MUST" requirement appears in RFC 2560? If not, then how could I include such a "MUST" requirement in 2560bis without breaking my promise not to make any changes to the protocol. This proposed change may be a good idea, but that doesn't mean it's not a change. You also say that "There really ought to be a requirement that implementations (of CA and OCSP software) MUST support short-lived OCSP signer certs...." Again, that may be a good idea, but can you find that requirement in RFC 2560? If not, then wouldn't including such a requirement in 2560bis be a change? The final paragraph in your message proposes reordering the checks in Section 2.3.6. However, the checks in Section 2.3.6 are listed in the same order as they appear in Section 3.2 of RFC 2560. While one could certainly reorder them without changing the protocol since the text does not specify that the checks need to be performed in the order they are listed, it would seem that reordering them would be inconsistent with the approach that you are advocating of "doing minimal changes to the original document." You also misrepresent RFC 5280 in your message. RFC 5280 very clearly allows CAs to sign CRLs with a different key than was used to sign the certificates covered by the CRL, and notes that it may be necessary for a relying party to build a separate certification path for the certificate needed to verify the signature on the CRL. As for OCSP, contrary to your assertion, relying parties are *NOT* required to be able to validate responses if the response (or the responder's certificate) was signed with a different key than the target certificate. I cannot find a single statement in RFC 2560 that states that conforming applications MUST be able to validate such responses, and so there is no such statement in 2560bis either. On 07/31/2012 09:53 PM, Martin Rex wrote: > Polk, William T. wrote: >> I would gladly support Option A if I thought it would produce a document >> that could produce interoperable implementations in a timely manner, >> but I just don't see it. > I do. Documenting only the differences and pointing out its values > has caused much greater adoption in the installed base of TLS for > changes such as secure renegotiation (rfc5746) or the SSL Beast > countermeasure through 1/(n-1) initial record splitting than > what you can see about adoption of TLSv1.1 over the last 6 years. >> Our experience with implementations of >> RFC 2560 has been decidedly mixed, and those implementations weren't >> particularly agile. I don't think a minor edit of 2560 will meet the >> need, so restarting will from 2560 will either produce a document that >> falls short or will take a lot more effort than Stefan believes. > This sounds like you're asking for _changing_ the existing protocol > by publishing a new spec with different or additional requirements. > > > On quick glance, the most significant "improvement" of -04 over rfc2560 > seems to be the examples in Appendix E. Carrying them over into -05 > should be simple and straightforward. > > What seems to be badly lacking in Appendix E of -04 is the requirements > of which certs MUST be included in the OCSP response for each of the > example CA/OCSP architecture/hierarchy, except for Figure 1 (where > no cert is necessary). > > What should be spelled out explicitly is that some of the depicted > architectures require an RP to be able to (a) build a certification > path (something that is *NOT* required for PKIX/rfc5280), and > in some cases (b) being able to distinguish certs with different > public keys from the same CA (=same issuer name) based on other > characteristics than issuer name (probably SubjectKeyIdentifier). > The latter is also *NOT* required for RPs by rfc5280 (the certificate > path validation algorithm in rfc5280 6.1 is entirely ignorant of > SubjectKeyIdentifiers). > > Revocation checking of the OCSP signer sounds like a very bad idea, > because it implies recursion. There really ought to be a requirement > that implementations (of CA and OCSP software) MUST support short-lived > OCSP signer certs that obviate cert revocation checking of a _seperate_ > OCSP signer cert entirely for the RP so that consumers of the technology > can configure&obtain interop with RPs that do not support such recursion. > > Looking at 2.3.6 Response Verification of -04, > the ordering of checks should IMHO rather be (1), (4), (5), (3), (2) > based on the current numbering of the items, i.e. one should only > perform public key crypto operation with a key that has > been verified as being trustworthy, similar to how the certificate > path validation in rfc5280 6.1 works. > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From d.w.chadwick@kent.ac.uk Wed Aug 1 08:50:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E6411E80D5 for ; Wed, 1 Aug 2012 08:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.632 X-Spam-Level: X-Spam-Status: No, score=-7.632 tagged_above=-999 required=5 tests=[AWL=0.967, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK8o5HEDA3zN for ; Wed, 1 Aug 2012 08:50:52 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6FD11E8087 for ; Wed, 1 Aug 2012 08:50:51 -0700 (PDT) Received: from mx4.kent.ac.uk ([129.12.21.35]) by mx1.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwbCD-0001tj-G9; Wed, 01 Aug 2012 16:50:49 +0100 Received: from [146.90.53.149] (helo=[192.168.1.39]) by mx4.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwbCC-0004JV-I2; Wed, 01 Aug 2012 16:50:49 +0100 Message-ID: <50195058.9090907@kent.ac.uk> Date: Wed, 01 Aug 2012 16:50:48 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Patrick Patterson References: <501847DC.5030509@ieca.com> <50191269.8090000@kent.ac.uk> <5E5299BC-836C-4BD3-A0EA-904B5EF3D8E2@carillon.ca> In-Reply-To: <5E5299BC-836C-4BD3-A0EA-904B5EF3D8E2@carillon.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 15:50:54 -0000 Hi Patrick I am talking from the perspective of the RP which, in the case of SAML, would be the SAML SP, which has received a SAML assertion which it needs to verify. On 01/08/2012 14:47, Patrick Patterson wrote: > Hi David, > > I'm not at all sure what you are talking about - I've never seen a > world where an RP gives anything to the PKI to verify - it usually > (when it is well behaved) extracts the certificate (after making sure > that the public key in the cert is the same that was used to sign the > message) and does RFC5280 Section 6 validation on it, or at least > makes sure this Certificate chains to a Trust Anchor that it has > pre-configured. In my opinion this is part of the PKI validation, not the PMI validation (section 6 is entitled certification path validation). The PKI roots of trust are configured into the PKI, not the PMI. The PMI would only have one or more PKI roots of trust configured into it, if it did not know who its trusted IDPs were, and was relying on the PKI to tell it. This is all done on the RP itself. the RP is the SAML IDP in the case of SAML assertions. It is relying on the PKI to validate the signatures on the signed messages (SAML assertions) that it receives. The RP knows the > semantics of the message that it has, and presumably (in the case of > SAML) knows who the authorised IDPs are (which may include, in this > case, checking to see if the claimSigning EKU is present). If the RP already knows who the trusted IDPs are, then there is no point in having the EKU field. All that is important is that the assertion is signed by the IDP, regardless of which key or certificate it used. The SAML SP should be insulated from the IDP migrating between keys and certificates - let the PKI component take care of this. I know that today's implementations pass around certificates in meta-data, but I regard this is as deficiency in trust validation. regards David > > I'm not asking for, or saying anything about signature semantics - > Stefan and Sean wanted a definition of a claim to be used when > asserting the "claimSigning" EKU, and I gave it to them. > > Cheers, > > Patrick. > > On 2012-08-01, at 7:26 AM, David Chadwick wrote: > >> Hi Patrick >> >> one problem see with this is as follows >> >> The RP typically gives a binary blob to the PKI and asks it to >> validate the signature on the binary blob. The PKI has no knowledge >> about the semantic content of this blob. So it cannot tell the >> difference between a SAML assertion, OpenID assertion, Oauth >> assertion, Word document, or a love letter. >> >> I dont think we should be building this sort of semantics into >> signature verification. >> >> regards >> >> David >> >> >> On 01/08/2012 03:11, Patrick Patterson wrote: >>> Hi Sean, >>> >>> We're currently working the definition of "claim" that we're >>> going to use and have come up with: >>> >>> "A signed claim is a set of attributes bound to a particular >>> subject using a digital signature in a way that relying parties >>> can make access or authorization decisions. >>> >>> The presence of the claimSigning EKU indicates that a CA has >>> approved the certificate holder to sign claims for use within a >>> specific community of interest (e.g., a Federation) according to >>> the rules of that community. In other words, the holder of a >>> certificate that asserts the claimSigning EKU can bind attributes >>> to a subject for processing by a relying party " >>> >>> What do people think about that? >>> >>> We'll be further augmenting this definition with clearer >>> examples, but the original one for use by an IDP is still my main >>> target (Matt has his own which will be made clear in the updated >>> draft :). We'll also be addressing a bit why the current status >>> quo may not work for everyone (and may not continue to work for >>> anyone if all certificates issued by major CAs that assert digSig >>> and nonRep start having mandatory populated EKU values). >>> >>> I'll talk to Stefan tomorrow, but I'm leaning towards withdrawing >>> our spot on the Agenda tomorrow, until we can come up with a >>> Draft that addresses the concerns posted. (There's also the >>> matter that Matt's not here, and I've got to leave before PKIX >>> tomorrow :( ) >>> >>> Cheers, >>> >>> Patrick. >>> >>> On 2012-07-31, at 5:02 PM, Sean Turner wrote: >>> >>>> I'm confused how a vague definition of a claim lines up with >>>> the need for a specific EKU (from Patrick's earlier message): >>>> >>>> Unfortunately, due to recent events regarding the abuse of >>>> certificates asserting Key Usage values of digitalSignature and >>>> nonRepudiation, a number of policy authorities are mandating >>>> strict EKU values in all certificates asserting these key usage >>>> values, and mandating by policy that the anyEKU OID not be >>>> present. >>>> >>>> You need a specific EKU to indicate you can sign a nebulous >>>> thing. What's the client going to check to know whether it's >>>> signing a claim or not? >>>> >>>> spt >>>> >>>> On 7/31/12 10:55 AM, Stefan Santesson wrote: >>>>> David, >>>>> >>>>> A broad definition of "Claim" may be appropriate, but there >>>>> need to be one. Absent a definition, the EKU becomes somewhat >>>>> pointless as usage declaration. >>>>> >>>>> /Stefan >>>>> >>>>> >>>>> >>>>> >>>>> On 12-07-31 10:37 AM, "David A. Cooper" >>>>> wrote: >>>>> >>>>>> Stefan, >>>>>> >>>>>> Based on earlier discussions that I've had with some of the >>>>>> editors of this document, I believe that the reason the >>>>>> draft isn't entirely clear about what might constitute a >>>>>> "Claim" is that there is a desire for the definition of >>>>>> this OID to be somewhat generic so that in the future, when >>>>>> a key purpose OID is needed to indicate that the subject >>>>>> is authorized to sign "claims," this OID can be used rather >>>>>> than having to define a new OID for each specific >>>>>> application. >>>>>> >>>>>> As an example, there are some signed CMS objects on PIV >>>>>> Cards. The CMS objects contain such things as biometric >>>>>> data of the cardholder and/or a unique identifier that has >>>>>> been assigned to the card. In FIPS 201, a key purpose OID >>>>>> was defined, id-PIV-content-signing, and there is a >>>>>> requirement that the signer of the CMS objects on the PIV >>>>>> Card must have a certificate that asserts the >>>>>> id-PIV-content-signing key purpose OID. When >>>>>> PIV-Interoperable cards were defined (similar to PIV Cards, >>>>>> but not issued by the U.S. Federal government), a new key >>>>>> purpose OID needed to be defined for the signers of the CMS >>>>>> objects on those cards, id-fpki-pivi-content-signing. It >>>>>> was noted that if there were a generic "claim signing" OID, >>>>>> then that OID could be used for both PIV and PIV-I Cards in >>>>>> addition to other cards that don't qualify as either PIV >>>>>> or PIV-I. We even received a comment on the current draft >>>>>> of FIPS 201 >>>>>> (http://csrc.nist.gov/publications/drafts/fips201-2/draft-fips-201-2_comme >>>>>> >>>>>> nts_disposition-for-2011-draft.pdf) >>>>>> asking that FIPS 201 specify the use of the claimSigning >>>>>> OID being discussed in the PKIX WG rather than (or in >>>>>> addition to) the id-PIV-content-signing OID. >>>>>> >>>>>> Dave >>>>>> >>>>>> On 07/30/2012 03:04 PM, Stefan Santesson wrote: >>>>>>> I have a number of issues/questions regarding this draft >>>>>>> (still). >>>>>>> >>>>>>> 1) Definition of "Claim" This EKU is said to state that >>>>>>> the subject is appropriate to sign "claims", but the >>>>>>> draft does not make an effort to define what a claim is. >>>>>>> It provides the examples SAML assertions and Attribute >>>>>>> Assertions, but does not state what else could be >>>>>>> regarded as a claim. Thus this EKU could be used for >>>>>>> virtually anything in absence of a clear definition. >>>>>>> >>>>>>> 2) Explain when this EKU is needed, relative to metadata >>>>>>> and pre-configured trust. The only examples are SAML. In >>>>>>> SAML it is common to either preconfigure trust in >>>>>>> assertion signers, removing the need for an EKU, or by >>>>>>> placing the cert in signed metadata also removing the >>>>>>> need for an EKU. What are the particular use-case where >>>>>>> you would neither use metadata, nor pre-configured >>>>>>> trust? A clarification of this would help the reader to >>>>>>> understand when this EKU is appropriate. >>>>>>> >>>>>>> 3) Discussion about assurance levels and policy OIDs. >>>>>>> When would you convey information about assurance level >>>>>>> of an assertion in a certificate policy of the signing >>>>>>> certificate? Information about assurance level is >>>>>>> provided in SAML requests and responses. Information >>>>>>> about what assurance level the IdP is trusted to provide >>>>>>> (certified for) is normally provided in signed metadata >>>>>>> (SAML) or may be implicit in the case of pre-configured >>>>>>> trust. When would it be appropriate to solve this using >>>>>>> cert policies? Is there any deployed examples of this? >>>>>>> >>>>>>> >>>>>>> /Stefan >>>>> >>>>> >>>>> _______________________________________________ pkix mailing >>>>> list pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>> >>>> _______________________________________________ pkix mailing >>>> list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>> >>> --- Patrick Patterson President and Chief PKI Architect Carillon >>> Information Security Inc. http://www.carillon.ca >>> >>> tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 >>> 9559 >>> >>> >>> >>> >>> >>> _______________________________________________ pkix mailing >>> list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>> > > --- Patrick Patterson President and Chief PKI Architect Carillon > Information Security Inc. http://www.carillon.ca > > tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 > > > > > From peterryb@gmail.com Wed Aug 1 04:47:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485DB21F8628 for ; Wed, 1 Aug 2012 04:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, VIRUS_WARNING_MYDOOM5=1.2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h84fEhzmXadw for ; Wed, 1 Aug 2012 04:47:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C36F021F8621 for ; Wed, 1 Aug 2012 04:47:31 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7480267vbb.31 for ; Wed, 01 Aug 2012 04:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7+P50XYQ5FEC6ro1mcy1tKPN/Jr5hfFvmuER58dw1DM=; b=eWMtBDqkRx7LcCy6tdIZEPi6yvRGh1dBHXexZ/+bNe3oc0bJGab2SKJqTUDbGcnqjj uByesE6N2rmo4m1dNEaRj1nLYIyJ3Ho1PGKAEal00F0uu6T9lS4Om+Wxb5Nr8v5RMO+k yMBoMa+r621Maq/EEeq4C+2AgfV7vSHWuaWG2YzoxT/QnQharJBk478GyVDLCBHjV1js WD84DVZd1HzK1Cg7tI0ZhLScKBba4RbZkUU4xW3BJq5NIKqSZKWLc8CT/9rBb45PfPTW jlvaxe6lLCrmi1zk5RY4x1z+zKLHcDbwF5HXIlFthpbps+Pu+4E5B7W/Uz4KanHsZsJT fICw== MIME-Version: 1.0 Received: by 10.220.225.194 with SMTP id it2mr16734848vcb.32.1343821650974; Wed, 01 Aug 2012 04:47:30 -0700 (PDT) Received: by 10.58.79.233 with HTTP; Wed, 1 Aug 2012 04:47:30 -0700 (PDT) In-Reply-To: <50191269.8090000@kent.ac.uk> References: <501847DC.5030509@ieca.com> <50191269.8090000@kent.ac.uk> Date: Wed, 1 Aug 2012 13:47:30 +0200 Message-ID: From: Peter Rybar To: David Chadwick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 01 Aug 2012 10:27:09 -0700 Cc: Patrick Patterson , "pkix@ietf.org" Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 11:47:33 -0000 Hi, The contentHint in CMS can be used for processing type identification of signed binary blob Attribute SEQUENCE { attrType OBJECT IDENTIFIER 1.2.840.113549.1.9.16.2.4 id-aa-contentHint attrValues SET { ContentHints SEQUENCE { contentDescription UTF8String =E2=80=98MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8; name=3D"Document.txt" Content-Disposition: attachment; filename=3D"Document.txt"=E2=80=98 contentType OBJECT IDENTIFIER 1.2.840.113549.1.7.1 id-data } } } Interoperability profile... http://www.nbusr.sk/en/electronic-signature/verification.1.html Peter 2012/8/1 David Chadwick : > Hi Patrick > > one problem see with this is as follows > > The RP typically gives a binary blob to the PKI and asks it to validate t= he > signature on the binary blob. The PKI has no knowledge about the semantic > content of this blob. So it cannot tell the difference between a SAML > assertion, OpenID assertion, Oauth assertion, Word document, or a love > letter. > > I dont think we should be building this sort of semantics into signature > verification. > > regards > > David > > > > On 01/08/2012 03:11, Patrick Patterson wrote: >> >> Hi Sean, >> >> We're currently working the definition of "claim" that we're going to us= e >> and have come up with: >> >> "A signed claim is a set of attributes bound to a particular subject usi= ng >> a digital signature in a way that relying parties can make access or >> authorization decisions. >> >> The presence of the claimSigning EKU indicates that a CA has approved th= e >> certificate holder to sign claims for use within a specific community of >> interest (e.g., a Federation) according to the rules of that community. = In >> other words, the holder of a certificate that asserts the claimSigning E= KU >> can bind attributes to a subject for processing by a relying party " >> >> What do people think about that? >> >> We'll be further augmenting this definition with clearer examples, but t= he >> original one for use by an IDP is still my main target (Matt has his own >> which will be made clear in the updated draft :). We'll also be addressi= ng a >> bit why the current status quo may not work for everyone (and may not >> continue to work for anyone if all certificates issued by major CAs that >> assert digSig and nonRep start having mandatory populated EKU values). >> >> I'll talk to Stefan tomorrow, but I'm leaning towards withdrawing our sp= ot >> on the Agenda tomorrow, until we can come up with a Draft that addresses= the >> concerns posted. (There's also the matter that Matt's not here, and I've= got >> to leave before PKIX tomorrow :( ) >> >> Cheers, >> >> Patrick. >> >> On 2012-07-31, at 5:02 PM, Sean Turner wrote: >> >>> I'm confused how a vague definition of a claim lines up with the need f= or >>> a specific EKU (from Patrick's earlier message): >>> >>> Unfortunately, due to recent events regarding the abuse >>> of certificates asserting Key Usage values of >>> digitalSignature and nonRepudiation, a number of policy >>> authorities are mandating strict EKU values in all >>> certificates asserting these key usage values, and >>> mandating by policy that the anyEKU OID not be present. >>> >>> You need a specific EKU to indicate you can sign a nebulous thing. What= 's >>> the client going to check to know whether it's signing a claim or not? >>> >>> spt >>> >>> On 7/31/12 10:55 AM, Stefan Santesson wrote: >>>> >>>> David, >>>> >>>> A broad definition of "Claim" may be appropriate, but there need to be >>>> one. >>>> Absent a definition, the EKU becomes somewhat pointless as usage >>>> declaration. >>>> >>>> /Stefan >>>> >>>> >>>> >>>> >>>> On 12-07-31 10:37 AM, "David A. Cooper" wrote: >>>> >>>>> Stefan, >>>>> >>>>> Based on earlier discussions that I've had with some of the editors o= f >>>>> this document, I believe that the reason the draft isn't entirely cle= ar >>>>> about what might constitute a "Claim" is that there is a desire for t= he >>>>> definition of this OID to be somewhat generic so that in the future, >>>>> when a key purpose OID is needed to indicate that the subject is >>>>> authorized to sign "claims," this OID can be used rather than having = to >>>>> define a new OID for each specific application. >>>>> >>>>> As an example, there are some signed CMS objects on PIV Cards. The CM= S >>>>> objects contain such things as biometric data of the cardholder and/o= r >>>>> a >>>>> unique identifier that has been assigned to the card. In FIPS 201, a >>>>> key purpose OID was defined, id-PIV-content-signing, and there is a >>>>> requirement that the signer of the CMS objects on the PIV Card must >>>>> have >>>>> a certificate that asserts the id-PIV-content-signing key purpose OID= . >>>>> When PIV-Interoperable cards were defined (similar to PIV Cards, but >>>>> not >>>>> issued by the U.S. Federal government), a new key purpose OID needed = to >>>>> be defined for the signers of the CMS objects on those cards, >>>>> id-fpki-pivi-content-signing. It was noted that if there were a >>>>> generic >>>>> "claim signing" OID, then that OID could be used for both PIV and PIV= -I >>>>> Cards in addition to other cards that don't qualify as either PIV or >>>>> PIV-I. We even received a comment on the current draft of FIPS 201 >>>>> >>>>> (http://csrc.nist.gov/publications/drafts/fips201-2/draft-fips-201-2_= comme >>>>> nts_disposition-for-2011-draft.pdf) >>>>> asking that FIPS 201 specify the use of the claimSigning OID being >>>>> discussed in the PKIX WG rather than (or in addition to) the >>>>> id-PIV-content-signing OID. >>>>> >>>>> Dave >>>>> >>>>> On 07/30/2012 03:04 PM, Stefan Santesson wrote: >>>>>> >>>>>> I have a number of issues/questions regarding this draft (still). >>>>>> >>>>>> 1) Definition of "Claim" >>>>>> This EKU is said to state that the subject is appropriate to sign >>>>>> "claims", but the draft does not make an effort to define what a cla= im >>>>>> is. >>>>>> It provides the examples SAML assertions and Attribute Assertions, b= ut >>>>>> does not state what else could be regarded as a claim. >>>>>> Thus this EKU could be used for virtually anything in absence of a >>>>>> clear >>>>>> definition. >>>>>> >>>>>> 2) Explain when this EKU is needed, relative to metadata and >>>>>> pre-configured trust. >>>>>> The only examples are SAML. In SAML it is common to either >>>>>> preconfigure >>>>>> trust in assertion signers, removing the need for an EKU, or by >>>>>> placing >>>>>> the cert in signed metadata also removing the need for an EKU. What >>>>>> are >>>>>> the particular use-case where you would neither use metadata, nor >>>>>> pre-configured trust? >>>>>> A clarification of this would help the reader to understand when thi= s >>>>>> EKU >>>>>> is appropriate. >>>>>> >>>>>> 3) Discussion about assurance levels and policy OIDs. >>>>>> When would you convey information about assurance level of an >>>>>> assertion >>>>>> in >>>>>> a certificate policy of the signing certificate? >>>>>> Information about assurance level is provided in SAML requests and >>>>>> responses. >>>>>> Information about what assurance level the IdP is trusted to provide >>>>>> (certified for) is normally provided in signed metadata (SAML) or ma= y >>>>>> be >>>>>> implicit in the case of pre-configured trust. >>>>>> When would it be appropriate to solve this using cert policies? >>>>>> Is there any deployed examples of this? >>>>>> >>>>>> >>>>>> /Stefan >>>> >>>> >>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >> --- >> Patrick Patterson >> President and Chief PKI Architect >> Carillon Information Security Inc. >> http://www.carillon.ca >> >> tel: +1 514 485 0789 >> mobile: +1 514 994 8699 >> fax: +1 450 424 9559 >> >> >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Wed Aug 1 10:46:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6537D11E8354 for ; Wed, 1 Aug 2012 10:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH5AjKuFQ2jw for ; Wed, 1 Aug 2012 10:46:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AD38F11E8353 for ; Wed, 1 Aug 2012 10:46:04 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60444 helo=dhcp-15b7.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Swczg-000HPA-2H for pkix@ietf.org; Wed, 01 Aug 2012 13:46:00 -0400 Message-ID: <50196B57.6070803@bbn.com> Date: Wed, 01 Aug 2012 13:45:59 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: pkix References: <953A4538-4301-4EB5-8D74-4601660264EC@fastq.com> In-Reply-To: <953A4538-4301-4EB5-8D74-4601660264EC@fastq.com> X-Forwarded-Message-Id: <953A4538-4301-4EB5-8D74-4601660264EC@fastq.com> Content-Type: multipart/alternative; boundary="------------080109060505050704020809" Subject: [pkix] Fwd: Re: 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:46:05 -0000 This is a multi-part message in MIME format. --------------080109060505050704020809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Re: [pkix] 2560bis Date: Tue, 31 Jul 2012 18:42:17 -0700 From: Michael Myers To: pkix PKIX CC: Stephen Kent , Stefan Santesson , "Polk, William T." Vote: I change my vote to option A. Notice: I assume I'm writing to just the three of you since I still can't get a fix on why my posts to PKIX bounce. I am at this very moment working with my ISP on the issue. But to the extent you are consolidating WG positions for a consensus on a path forward, there's mine. Essay: The key that signs the response need not be the key that signed the cert. That capability MUST be maintained to enable an effective distribution of authority. I know well the original language is at times ambiguous, the reasons for which have likely been overcome by events. Mike --------------080109060505050704020809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit


-------- Original Message --------
Subject: Re: [pkix] 2560bis
Date: Tue, 31 Jul 2012 18:42:17 -0700
From: Michael Myers <mmyers@fastq.com>
To: pkix PKIX <pkix@ietf.org>
CC: Stephen Kent <kent@bbn.com>, Stefan Santesson <stefan@aaa-sec.com>, "Polk, William T." <william.polk@nist.gov> 


Vote:  I change my vote to option A.

Notice:  I assume I'm writing to just the three of you since I still  
can't get a fix on why my posts to PKIX bounce.  I am at this very  
moment working with my ISP on the issue. But to the extent you are  
consolidating WG positions for a consensus on a path forward, there's  
mine.

Essay:  The key that signs the response need not be the key that  
signed the cert.  That capability MUST be maintained to enable an  
effective distribution of authority.  I know well the original  
language is at times ambiguous, the reasons for which have likely been  
overcome by events.

Mike



--------------080109060505050704020809-- From trevorf@exchange.microsoft.com Wed Aug 1 10:51:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D73911E83AB for ; Wed, 1 Aug 2012 10:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq0uDKxnauAg for ; Wed, 1 Aug 2012 10:51:21 -0700 (PDT) Received: from na01b.map.o365filtering.com (sn2c-ob.o365filtering.com [157.55.158.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3970711E8357 for ; Wed, 1 Aug 2012 10:51:21 -0700 (PDT) Received: from BLUSR01CA103.namsdf01.sdf.exchangelabs.com (10.255.124.148) by BLUSR01MB603.namsdf01.sdf.exchangelabs.com (10.255.124.168) with Microsoft SMTP Server (TLS) id 15.0.485.4; Wed, 1 Aug 2012 17:51:05 +0000 Received: from SN2FFOFD003.ffo.gbl (157.55.158.23) by BLUSR01CA103.namsdf01.sdf.exchangelabs.com (10.255.124.148) with Microsoft SMTP Server (TLS) id 15.0.485.4; Wed, 1 Aug 2012 17:51:05 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.27) by SN2FFOFD003.mail.o365filtering.com (10.111.201.40) with Microsoft SMTP Server (TLS) id 15.0.485.0; Wed, 1 Aug 2012 17:51:04 +0000 Received: from DFM-TK5MBX15-08.exchange.corp.microsoft.com (157.54.109.47) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.71.0; Wed, 1 Aug 2012 10:50:43 -0700 Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DFM-TK5MBX15-08.exchange.corp.microsoft.com (157.54.109.47) with Microsoft SMTP Server (TLS) id 15.0.466.15; Wed, 1 Aug 2012 10:50:42 -0700 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.03.0071.000; Wed, 1 Aug 2012 10:50:42 -0700 From: Trevor Freeman To: David Chadwick , Patrick Patterson Thread-Topic: [pkix] Updated claimSigning EKU Internet Draft Thread-Index: AQHNaz6Da2j+4WxoJ0afqzBXvMsVc5dCqzIAgAF594CAAAUVAIAANCkAgABWS4CAAJsrgIAAJ1EAgAAihAD//6m10A== Date: Wed, 1 Aug 2012 17:50:41 +0000 Message-ID: References: <501847DC.5030509@ieca.com> <50191269.8090000@kent.ac.uk> <5E5299BC-836C-4BD3-A0EA-904B5EF3D8E2@carillon.ca> <50195058.9090907@kent.ac.uk> In-Reply-To: <50195058.9090907@kent.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.94.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.27; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(13464001)(45074001)(43544002)(407274001)(377454001)(377424002)(24454001)(51704002)(33656001)(16406001)(42186003)(266001)(31966006); DIR:INB; LANG:en; X-Forefront-PRVS: 0560A2214D X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:51:23 -0000 David, I am somewhat baffled by your comment. There is a long precedence for refin= ing the sign semantics of the key used extension via the eku extension to e= xpress sign what. We have signed code, signed documents, signed revocation = responses eku purposes. The whole purpose of the EKU extension was to enabl= e this kind of expression. The RP absolutely understands if it is processin= g claims so can filter based on EKU. We should not be inventing new semantics for different kinds of signing. Trevor -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Dav= id Chadwick Sent: Wednesday, August 01, 2012 8:51 AM To: Patrick Patterson Cc: pkix@ietf.org PKIX Subject: Re: [pkix] Updated claimSigning EKU Internet Draft Hi Patrick I am talking from the perspective of the RP which, in the case of SAML, wou= ld be the SAML SP, which has received a SAML assertion which it needs to ve= rify. On 01/08/2012 14:47, Patrick Patterson wrote: > Hi David, > > I'm not at all sure what you are talking about - I've never seen a=20 > world where an RP gives anything to the PKI to verify - it usually=20 > (when it is well behaved) extracts the certificate (after making sure=20 > that the public key in the cert is the same that was used to sign the > message) and does RFC5280 Section 6 validation on it, or at least=20 > makes sure this Certificate chains to a Trust Anchor that it has=20 > pre-configured. In my opinion this is part of the PKI validation, not the PMI validation (s= ection 6 is entitled certification path validation). The PKI roots of trust= are configured into the PKI, not the PMI. The PMI would only have one or m= ore PKI roots of trust configured into it, if it did not know who its trust= ed IDPs were, and was relying on the PKI to tell it. This is all done on the RP itself. the RP is the SAML IDP in the case of SAML assertions. It is relying on the= PKI to validate the signatures on the signed messages (SAML assertions) that it receives. The RP knows the > semantics of the message that it has, and presumably (in the case of > SAML) knows who the authorised IDPs are (which may include, in this=20 > case, checking to see if the claimSigning EKU is present). If the RP already knows who the trusted IDPs are, then there is no point in= having the EKU field. All that is important is that the assertion is signe= d by the IDP, regardless of which key or certificate it used. The SAML SP s= hould be insulated from the IDP migrating between keys and certificates - l= et the PKI component take care of this. I know that today's implementations= pass around certificates in meta-data, but I regard this is as deficiency = in trust validation. regards David > > I'm not asking for, or saying anything about signature semantics -=20 > Stefan and Sean wanted a definition of a claim to be used when=20 > asserting the "claimSigning" EKU, and I gave it to them. > > Cheers, > > Patrick. > > On 2012-08-01, at 7:26 AM, David Chadwick wrote: > >> Hi Patrick >> >> one problem see with this is as follows >> >> The RP typically gives a binary blob to the PKI and asks it to=20 >> validate the signature on the binary blob. The PKI has no knowledge=20 >> about the semantic content of this blob. So it cannot tell the=20 >> difference between a SAML assertion, OpenID assertion, Oauth=20 >> assertion, Word document, or a love letter. >> >> I dont think we should be building this sort of semantics into=20 >> signature verification. >> >> regards >> >> David >> >> >> On 01/08/2012 03:11, Patrick Patterson wrote: >>> Hi Sean, >>> >>> We're currently working the definition of "claim" that we're going=20 >>> to use and have come up with: >>> >>> "A signed claim is a set of attributes bound to a particular subject=20 >>> using a digital signature in a way that relying parties can make=20 >>> access or authorization decisions. >>> >>> The presence of the claimSigning EKU indicates that a CA has=20 >>> approved the certificate holder to sign claims for use within a=20 >>> specific community of interest (e.g., a Federation) according to the=20 >>> rules of that community. In other words, the holder of a certificate=20 >>> that asserts the claimSigning EKU can bind attributes to a subject=20 >>> for processing by a relying party " >>> >>> What do people think about that? >>> >>> We'll be further augmenting this definition with clearer examples,=20 >>> but the original one for use by an IDP is still my main target (Matt=20 >>> has his own which will be made clear in the updated draft :). We'll=20 >>> also be addressing a bit why the current status quo may not work for=20 >>> everyone (and may not continue to work for anyone if all=20 >>> certificates issued by major CAs that assert digSig and nonRep start=20 >>> having mandatory populated EKU values). >>> >>> I'll talk to Stefan tomorrow, but I'm leaning towards withdrawing=20 >>> our spot on the Agenda tomorrow, until we can come up with a Draft=20 >>> that addresses the concerns posted. (There's also the matter that=20 >>> Matt's not here, and I've got to leave before PKIX tomorrow :( ) >>> >>> Cheers, >>> >>> Patrick. >>> >>> On 2012-07-31, at 5:02 PM, Sean Turner wrote: >>> >>>> I'm confused how a vague definition of a claim lines up with the=20 >>>> need for a specific EKU (from Patrick's earlier message): >>>> >>>> Unfortunately, due to recent events regarding the abuse of=20 >>>> certificates asserting Key Usage values of digitalSignature and=20 >>>> nonRepudiation, a number of policy authorities are mandating strict=20 >>>> EKU values in all certificates asserting these key usage values,=20 >>>> and mandating by policy that the anyEKU OID not be present. >>>> >>>> You need a specific EKU to indicate you can sign a nebulous thing.=20 >>>> What's the client going to check to know whether it's signing a=20 >>>> claim or not? >>>> >>>> spt >>>> >>>> On 7/31/12 10:55 AM, Stefan Santesson wrote: >>>>> David, >>>>> >>>>> A broad definition of "Claim" may be appropriate, but there need=20 >>>>> to be one. Absent a definition, the EKU becomes somewhat pointless=20 >>>>> as usage declaration. >>>>> >>>>> /Stefan >>>>> >>>>> >>>>> >>>>> >>>>> On 12-07-31 10:37 AM, "David A. Cooper" >>>>> wrote: >>>>> >>>>>> Stefan, >>>>>> >>>>>> Based on earlier discussions that I've had with some of the=20 >>>>>> editors of this document, I believe that the reason the draft=20 >>>>>> isn't entirely clear about what might constitute a "Claim" is=20 >>>>>> that there is a desire for the definition of this OID to be=20 >>>>>> somewhat generic so that in the future, when a key purpose OID is=20 >>>>>> needed to indicate that the subject is authorized to sign=20 >>>>>> "claims," this OID can be used rather than having to define a new=20 >>>>>> OID for each specific application. >>>>>> >>>>>> As an example, there are some signed CMS objects on PIV Cards.=20 >>>>>> The CMS objects contain such things as biometric data of the=20 >>>>>> cardholder and/or a unique identifier that has been assigned to=20 >>>>>> the card. In FIPS 201, a key purpose OID was defined,=20 >>>>>> id-PIV-content-signing, and there is a requirement that the=20 >>>>>> signer of the CMS objects on the PIV Card must have a certificate=20 >>>>>> that asserts the id-PIV-content-signing key purpose OID. When=20 >>>>>> PIV-Interoperable cards were defined (similar to PIV Cards, but=20 >>>>>> not issued by the U.S. Federal government), a new key purpose OID=20 >>>>>> needed to be defined for the signers of the CMS objects on those=20 >>>>>> cards, id-fpki-pivi-content-signing. It was noted that if there=20 >>>>>> were a generic "claim signing" OID, then that OID could be used=20 >>>>>> for both PIV and PIV-I Cards in addition to other cards that=20 >>>>>> don't qualify as either PIV or PIV-I. We even received a comment=20 >>>>>> on the current draft of FIPS 201=20 >>>>>> (http://csrc.nist.gov/publications/drafts/fips201-2/draft-fips-20 >>>>>> 1-2_comme >>>>>> >>>>>> nts_disposition-for-2011-draft.pdf) >>>>>> asking that FIPS 201 specify the use of the claimSigning OID=20 >>>>>> being discussed in the PKIX WG rather than (or in addition to)=20 >>>>>> the id-PIV-content-signing OID. >>>>>> >>>>>> Dave >>>>>> >>>>>> On 07/30/2012 03:04 PM, Stefan Santesson wrote: >>>>>>> I have a number of issues/questions regarding this draft=20 >>>>>>> (still). >>>>>>> >>>>>>> 1) Definition of "Claim" This EKU is said to state that the=20 >>>>>>> subject is appropriate to sign "claims", but the draft does not=20 >>>>>>> make an effort to define what a claim is. >>>>>>> It provides the examples SAML assertions and Attribute=20 >>>>>>> Assertions, but does not state what else could be regarded as a=20 >>>>>>> claim. Thus this EKU could be used for virtually anything in=20 >>>>>>> absence of a clear definition. >>>>>>> >>>>>>> 2) Explain when this EKU is needed, relative to metadata and=20 >>>>>>> pre-configured trust. The only examples are SAML. In SAML it is=20 >>>>>>> common to either preconfigure trust in assertion signers,=20 >>>>>>> removing the need for an EKU, or by placing the cert in signed=20 >>>>>>> metadata also removing the need for an EKU. What are the=20 >>>>>>> particular use-case where you would neither use metadata, nor=20 >>>>>>> pre-configured trust? A clarification of this would help the=20 >>>>>>> reader to understand when this EKU is appropriate. >>>>>>> >>>>>>> 3) Discussion about assurance levels and policy OIDs. >>>>>>> When would you convey information about assurance level of an=20 >>>>>>> assertion in a certificate policy of the signing certificate?=20 >>>>>>> Information about assurance level is provided in SAML requests=20 >>>>>>> and responses. Information about what assurance level the IdP is=20 >>>>>>> trusted to provide (certified for) is normally provided in=20 >>>>>>> signed metadata >>>>>>> (SAML) or may be implicit in the case of pre-configured trust.=20 >>>>>>> When would it be appropriate to solve this using cert policies?=20 >>>>>>> Is there any deployed examples of this? >>>>>>> >>>>>>> >>>>>>> /Stefan >>>>> >>>>> >>>>> _______________________________________________ pkix mailing list=20 >>>>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>>>> >>>> _______________________________________________ pkix mailing list=20 >>>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>> >>> --- Patrick Patterson President and Chief PKI Architect Carillon=20 >>> Information Security Inc. http://www.carillon.ca >>> >>> tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 >>> 9559 >>> >>> >>> >>> >>> >>> _______________________________________________ pkix mailing list=20 >>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>> > > --- Patrick Patterson President and Chief PKI Architect Carillon=20 > Information Security Inc. http://www.carillon.ca > > tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 > > > > > _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Wed Aug 1 13:23:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8527B11E8173 for ; Wed, 1 Aug 2012 13:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.192 X-Spam-Level: X-Spam-Status: No, score=-10.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWGTSHo+KcR2 for ; Wed, 1 Aug 2012 13:23:07 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A713311E810A for ; Wed, 1 Aug 2012 13:23:06 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q71KMgg4019657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Aug 2012 22:22:42 +0200 (MEST) In-Reply-To: To: Santosh Chokhani Date: Wed, 1 Aug 2012 22:22:42 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120801202242.50D1E1A10B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] new text for 5280bis, Section 3.2 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:23:07 -0000 Santosh Chokhani wrote: > > How about the following: > > Consistent with Section 3.4.61 of X.509 (11/2008) we note that use of > self-issued certificates and self-signed certificates when issued by > entities other than CAs are outside the scope of this specification. > Thus, for example, a web server or client might generate a self-signed > certificate to identity itself. These certificates, and how a relying > party uses them to authenticate asserted identities, are both outside > the scope of RFC 5280. OT: >From the parallel discussion thread about OCSP 2560bis, I noticed a throroughly confusing example in Appendix E.3 Locally Trusted OCSP Responder at the end of -04 document: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-04#page-42 which uses a self-signed certificate of a non-CA entity. This is outside of PKIX/rfc5280 and an option not listed under 2.3.5.2: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-04#section-2.3.5.2 and looks to _me_ like a bad idea in general. -Martin From d.w.chadwick@kent.ac.uk Wed Aug 1 13:35:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E38711E8236 for ; Wed, 1 Aug 2012 13:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veR5IlYNR+5j for ; Wed, 1 Aug 2012 13:35:10 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEEA21F851E for ; Wed, 1 Aug 2012 13:34:58 -0700 (PDT) Received: from mx4.kent.ac.uk ([129.12.21.35]) by mx1.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Swfd6-0006SW-Dz; Wed, 01 Aug 2012 21:34:52 +0100 Received: from [31.185.215.137] (helo=[192.168.1.38]) by mx4.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Swfd5-00063Y-LH; Wed, 01 Aug 2012 21:34:52 +0100 Message-ID: <501992EB.5030501@kent.ac.uk> Date: Wed, 01 Aug 2012 21:34:51 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Trevor Freeman References: <501847DC.5030509@ieca.com> <50191269.8090000@kent.ac.uk> <5E5299BC-836C-4BD3-A0EA-904B5EF3D8E2@carillon.ca> <50195058.9090907@kent.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Patrick Patterson , "pkix@ietf.org PKIX" Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:35:19 -0000 Hi Trevor there is one big difference in all these cases your mention and that of a PMI claim which I mention, namely, the RPs are either all applications (signed code, signed documents) or PKI components (revocation) that are using the PKI to validate its signed documents. Thus the PKI is the *only* security component the RP is relying on, whilst in the case of validating a PMI claim, the PMI is actually part of the security infrastructure itself (on a par with the PKI). Thus the PMI does not need to rely on the PKI to the same extent as the other components. It is fully capable of validating its own trust chains. The PMI forms a parallel infrastructure to the PKI. regards David On 01/08/2012 18:50, Trevor Freeman wrote: > David, > > I am somewhat baffled by your comment. There is a long precedence for > refining the sign semantics of the key used extension via the eku > extension to express sign what. We have signed code, signed > documents, signed revocation responses eku purposes. The whole > purpose of the EKU extension was to enable this kind of expression. > The RP absolutely understands if it is processing claims so can > filter based on EKU. We should not be inventing new semantics for > different kinds of signing. > > Trevor -----Original Message----- From: pkix-bounces@ietf.org > [mailto:pkix-bounces@ietf.org] On Behalf Of David Chadwick Sent: > Wednesday, August 01, 2012 8:51 AM To: Patrick Patterson Cc: > pkix@ietf.org PKIX Subject: Re: [pkix] Updated claimSigning EKU > Internet Draft > > Hi Patrick > > I am talking from the perspective of the RP which, in the case of > SAML, would be the SAML SP, which has received a SAML assertion which > it needs to verify. > > On 01/08/2012 14:47, Patrick Patterson wrote: >> Hi David, >> >> I'm not at all sure what you are talking about - I've never seen a >> world where an RP gives anything to the PKI to verify - it usually >> (when it is well behaved) extracts the certificate (after making >> sure that the public key in the cert is the same that was used to >> sign the message) and does RFC5280 Section 6 validation on it, or >> at least makes sure this Certificate chains to a Trust Anchor that >> it has pre-configured. > > In my opinion this is part of the PKI validation, not the PMI > validation (section 6 is entitled certification path validation). The > PKI roots of trust are configured into the PKI, not the PMI. The PMI > would only have one or more PKI roots of trust configured into it, if > it did not know who its trusted IDPs were, and was relying on the PKI > to tell it. > > This is all done on the RP itself. > > the RP is the SAML IDP in the case of SAML assertions. It is relying > on the PKI to validate the signatures on the signed messages (SAML > assertions) that it receives. > > The RP knows the >> semantics of the message that it has, and presumably (in the case >> of SAML) knows who the authorised IDPs are (which may include, in >> this case, checking to see if the claimSigning EKU is present). > > If the RP already knows who the trusted IDPs are, then there is no > point in having the EKU field. All that is important is that the > assertion is signed by the IDP, regardless of which key or > certificate it used. The SAML SP should be insulated from the IDP > migrating between keys and certificates - let the PKI component take > care of this. I know that today's implementations pass around > certificates in meta-data, but I regard this is as deficiency in > trust validation. > > regards > > David > > >> >> I'm not asking for, or saying anything about signature semantics - >> Stefan and Sean wanted a definition of a claim to be used when >> asserting the "claimSigning" EKU, and I gave it to them. >> >> Cheers, >> >> Patrick. >> >> On 2012-08-01, at 7:26 AM, David Chadwick wrote: >> >>> Hi Patrick >>> >>> one problem see with this is as follows >>> >>> The RP typically gives a binary blob to the PKI and asks it to >>> validate the signature on the binary blob. The PKI has no >>> knowledge about the semantic content of this blob. So it cannot >>> tell the difference between a SAML assertion, OpenID assertion, >>> Oauth assertion, Word document, or a love letter. >>> >>> I dont think we should be building this sort of semantics into >>> signature verification. >>> >>> regards >>> >>> David >>> >>> >>> On 01/08/2012 03:11, Patrick Patterson wrote: >>>> Hi Sean, >>>> >>>> We're currently working the definition of "claim" that we're >>>> going to use and have come up with: >>>> >>>> "A signed claim is a set of attributes bound to a particular >>>> subject using a digital signature in a way that relying parties >>>> can make access or authorization decisions. >>>> >>>> The presence of the claimSigning EKU indicates that a CA has >>>> approved the certificate holder to sign claims for use within >>>> a specific community of interest (e.g., a Federation) according >>>> to the rules of that community. In other words, the holder of a >>>> certificate that asserts the claimSigning EKU can bind >>>> attributes to a subject for processing by a relying party " >>>> >>>> What do people think about that? >>>> >>>> We'll be further augmenting this definition with clearer >>>> examples, but the original one for use by an IDP is still my >>>> main target (Matt has his own which will be made clear in the >>>> updated draft :). We'll also be addressing a bit why the >>>> current status quo may not work for everyone (and may not >>>> continue to work for anyone if all certificates issued by major >>>> CAs that assert digSig and nonRep start having mandatory >>>> populated EKU values). >>>> >>>> I'll talk to Stefan tomorrow, but I'm leaning towards >>>> withdrawing our spot on the Agenda tomorrow, until we can come >>>> up with a Draft that addresses the concerns posted. (There's >>>> also the matter that Matt's not here, and I've got to leave >>>> before PKIX tomorrow :( ) >>>> >>>> Cheers, >>>> >>>> Patrick. >>>> >>>> On 2012-07-31, at 5:02 PM, Sean Turner wrote: >>>> >>>>> I'm confused how a vague definition of a claim lines up with >>>>> the need for a specific EKU (from Patrick's earlier >>>>> message): >>>>> >>>>> Unfortunately, due to recent events regarding the abuse of >>>>> certificates asserting Key Usage values of digitalSignature >>>>> and nonRepudiation, a number of policy authorities are >>>>> mandating strict EKU values in all certificates asserting >>>>> these key usage values, and mandating by policy that the >>>>> anyEKU OID not be present. >>>>> >>>>> You need a specific EKU to indicate you can sign a nebulous >>>>> thing. What's the client going to check to know whether it's >>>>> signing a claim or not? >>>>> >>>>> spt >>>>> >>>>> On 7/31/12 10:55 AM, Stefan Santesson wrote: >>>>>> David, >>>>>> >>>>>> A broad definition of "Claim" may be appropriate, but there >>>>>> need to be one. Absent a definition, the EKU becomes >>>>>> somewhat pointless as usage declaration. >>>>>> >>>>>> /Stefan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 12-07-31 10:37 AM, "David A. Cooper" >>>>>> wrote: >>>>>> >>>>>>> Stefan, >>>>>>> >>>>>>> Based on earlier discussions that I've had with some of >>>>>>> the editors of this document, I believe that the reason >>>>>>> the draft isn't entirely clear about what might >>>>>>> constitute a "Claim" is that there is a desire for the >>>>>>> definition of this OID to be somewhat generic so that in >>>>>>> the future, when a key purpose OID is needed to indicate >>>>>>> that the subject is authorized to sign "claims," this OID >>>>>>> can be used rather than having to define a new OID for >>>>>>> each specific application. >>>>>>> >>>>>>> As an example, there are some signed CMS objects on PIV >>>>>>> Cards. The CMS objects contain such things as biometric >>>>>>> data of the cardholder and/or a unique identifier that >>>>>>> has been assigned to the card. In FIPS 201, a key >>>>>>> purpose OID was defined, id-PIV-content-signing, and >>>>>>> there is a requirement that the signer of the CMS objects >>>>>>> on the PIV Card must have a certificate that asserts the >>>>>>> id-PIV-content-signing key purpose OID. When >>>>>>> PIV-Interoperable cards were defined (similar to PIV >>>>>>> Cards, but not issued by the U.S. Federal government), a >>>>>>> new key purpose OID needed to be defined for the signers >>>>>>> of the CMS objects on those cards, >>>>>>> id-fpki-pivi-content-signing. It was noted that if >>>>>>> there were a generic "claim signing" OID, then that OID >>>>>>> could be used for both PIV and PIV-I Cards in addition to >>>>>>> other cards that don't qualify as either PIV or PIV-I. >>>>>>> We even received a comment on the current draft of FIPS >>>>>>> 201 >>>>>>> (http://csrc.nist.gov/publications/drafts/fips201-2/draft-fips-20 >>>>>>> >>>>>>> 1-2_comme >>>>>>> >>>>>>> > nts_disposition-for-2011-draft.pdf) >>>>>>> asking that FIPS 201 specify the use of the claimSigning >>>>>>> OID being discussed in the PKIX WG rather than (or in >>>>>>> addition to) the id-PIV-content-signing OID. >>>>>>> >>>>>>> Dave >>>>>>> >>>>>>> On 07/30/2012 03:04 PM, Stefan Santesson wrote: >>>>>>>> I have a number of issues/questions regarding this >>>>>>>> draft (still). >>>>>>>> >>>>>>>> 1) Definition of "Claim" This EKU is said to state that >>>>>>>> the subject is appropriate to sign "claims", but the >>>>>>>> draft does not make an effort to define what a claim >>>>>>>> is. It provides the examples SAML assertions and >>>>>>>> Attribute Assertions, but does not state what else >>>>>>>> could be regarded as a claim. Thus this EKU could be >>>>>>>> used for virtually anything in absence of a clear >>>>>>>> definition. >>>>>>>> >>>>>>>> 2) Explain when this EKU is needed, relative to >>>>>>>> metadata and pre-configured trust. The only examples >>>>>>>> are SAML. In SAML it is common to either preconfigure >>>>>>>> trust in assertion signers, removing the need for an >>>>>>>> EKU, or by placing the cert in signed metadata also >>>>>>>> removing the need for an EKU. What are the particular >>>>>>>> use-case where you would neither use metadata, nor >>>>>>>> pre-configured trust? A clarification of this would >>>>>>>> help the reader to understand when this EKU is >>>>>>>> appropriate. >>>>>>>> >>>>>>>> 3) Discussion about assurance levels and policy OIDs. >>>>>>>> When would you convey information about assurance level >>>>>>>> of an assertion in a certificate policy of the signing >>>>>>>> certificate? Information about assurance level is >>>>>>>> provided in SAML requests and responses. Information >>>>>>>> about what assurance level the IdP is trusted to >>>>>>>> provide (certified for) is normally provided in signed >>>>>>>> metadata (SAML) or may be implicit in the case of >>>>>>>> pre-configured trust. When would it be appropriate to >>>>>>>> solve this using cert policies? Is there any deployed >>>>>>>> examples of this? >>>>>>>> >>>>>>>> >>>>>>>> /Stefan >>>>>> >>>>>> >>>>>> _______________________________________________ pkix >>>>>> mailing list pkix@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>> >>>>> _______________________________________________ pkix mailing >>>>> list pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>>> --- Patrick Patterson President and Chief PKI Architect >>>> Carillon Information Security Inc. http://www.carillon.ca >>>> >>>> tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 >>>> 9559 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ pkix mailing >>>> list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>>> >> >> --- Patrick Patterson President and Chief PKI Architect Carillon >> Information Security Inc. http://www.carillon.ca >> >> tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 >> >> >> >> >> > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix > From ppatterson@carillon.ca Wed Aug 1 13:59:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA99D11E82FF for ; Wed, 1 Aug 2012 13:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEYjcC6WOvm6 for ; Wed, 1 Aug 2012 13:59:53 -0700 (PDT) Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5788511E82ED for ; Wed, 1 Aug 2012 13:59:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id DCAE9A811A2; Wed, 1 Aug 2012 17:00:01 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at rhea-new.carillon.ca Received: from mail.carillon.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIj52oepFYXQ; Wed, 1 Aug 2012 17:00:00 -0400 (EDT) Received: from [10.255.254.125] (s142-179-109-14.bc.hsia.telus.net [142.179.109.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTPSA id 92981A804FC; Wed, 1 Aug 2012 16:59:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Patrick Patterson In-Reply-To: <501992EB.5030501@kent.ac.uk> Date: Wed, 1 Aug 2012 16:59:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0BEB4006-5762-42A5-BEC8-24F79A4184CF@carillon.ca> References: <501847DC.5030509@ieca.com> <50191269.8090000@kent.ac.uk> <5E5299BC-836C-4BD3-A0EA-904B5EF3D8E2@carillon.ca> <50195058.9090907@kent.ac.uk> <501992EB.5030501@kent.ac.uk> To: David Chadwick X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:59:55 -0000 Hello David, I think that your assumption only works in the case where the PMI = operates their own CA (that signs only Metadata and/or IDP = certificates).=20 In a couple of cases that I am aware of, the same CA that issues = Identity Certificates, general Purpose Device Certificates, there is a = desire issue IDP Certs, and distinguish these from general purpose = Device certificates.=20 Furthermore, IDPs may be part of a dynamic Federation (it is sufficient = to be part of the same PKI Community - we're treating Attribute = Assurance separately), and therefore there IS no metadata. Consequently, = the PMI and the PKI may be part of the same Trust Infrastructure, and = therefore are not considered independent. There are many models for Federation that are emerging, and we need to = have a way to support these. Cheers, Patrick. On 2012-08-01, at 4:34 PM, David Chadwick wrote: > Hi Trevor >=20 > there is one big difference in all these cases your mention and that = of > a PMI claim which I mention, namely, the RPs are either all = applications (signed code, signed documents) or PKI components = (revocation) that are using the PKI to validate its signed documents. = Thus the PKI is the *only* security component the RP is relying on, = whilst in the case of validating a PMI claim, the PMI is actually part = of the security infrastructure itself (on a par with the PKI). Thus the = PMI does not need to rely on the PKI to the same extent as the other = components. It is fully capable of validating its own trust chains. The = PMI forms a parallel infrastructure to the PKI. >=20 > regards >=20 > David >=20 > On 01/08/2012 18:50, Trevor Freeman wrote: >> David, >>=20 >> I am somewhat baffled by your comment. There is a long precedence for >> refining the sign semantics of the key used extension via the eku >> extension to express sign what. We have signed code, signed >> documents, signed revocation responses eku purposes. The whole >> purpose of the EKU extension was to enable this kind of expression. >> The RP absolutely understands if it is processing claims so can >> filter based on EKU. We should not be inventing new semantics for >> different kinds of signing. >>=20 >> Trevor -----Original Message----- From: pkix-bounces@ietf.org >> [mailto:pkix-bounces@ietf.org] On Behalf Of David Chadwick Sent: >> Wednesday, August 01, 2012 8:51 AM To: Patrick Patterson Cc: >> pkix@ietf.org PKIX Subject: Re: [pkix] Updated claimSigning EKU >> Internet Draft >>=20 >> Hi Patrick >>=20 >> I am talking from the perspective of the RP which, in the case of >> SAML, would be the SAML SP, which has received a SAML assertion which >> it needs to verify. >>=20 >> On 01/08/2012 14:47, Patrick Patterson wrote: >>> Hi David, >>>=20 >>> I'm not at all sure what you are talking about - I've never seen a >>> world where an RP gives anything to the PKI to verify - it usually >>> (when it is well behaved) extracts the certificate (after making >>> sure that the public key in the cert is the same that was used to >>> sign the message) and does RFC5280 Section 6 validation on it, or >>> at least makes sure this Certificate chains to a Trust Anchor that >>> it has pre-configured. >>=20 >> In my opinion this is part of the PKI validation, not the PMI >> validation (section 6 is entitled certification path validation). The >> PKI roots of trust are configured into the PKI, not the PMI. The PMI >> would only have one or more PKI roots of trust configured into it, if >> it did not know who its trusted IDPs were, and was relying on the PKI >> to tell it. >>=20 >> This is all done on the RP itself. >>=20 >> the RP is the SAML IDP in the case of SAML assertions. It is relying >> on the PKI to validate the signatures on the signed messages (SAML >> assertions) that it receives. >>=20 >> The RP knows the >>> semantics of the message that it has, and presumably (in the case >>> of SAML) knows who the authorised IDPs are (which may include, in >>> this case, checking to see if the claimSigning EKU is present). >>=20 >> If the RP already knows who the trusted IDPs are, then there is no >> point in having the EKU field. All that is important is that the >> assertion is signed by the IDP, regardless of which key or >> certificate it used. The SAML SP should be insulated from the IDP >> migrating between keys and certificates - let the PKI component take >> care of this. I know that today's implementations pass around >> certificates in meta-data, but I regard this is as deficiency in >> trust validation. >>=20 >> regards >>=20 >> David >>=20 >>=20 >>>=20 >>> I'm not asking for, or saying anything about signature semantics - >>> Stefan and Sean wanted a definition of a claim to be used when >>> asserting the "claimSigning" EKU, and I gave it to them. >>>=20 >>> Cheers, >>>=20 >>> Patrick. >>>=20 >>> On 2012-08-01, at 7:26 AM, David Chadwick wrote: >>>=20 >>>> Hi Patrick >>>>=20 >>>> one problem see with this is as follows >>>>=20 >>>> The RP typically gives a binary blob to the PKI and asks it to >>>> validate the signature on the binary blob. The PKI has no >>>> knowledge about the semantic content of this blob. So it cannot >>>> tell the difference between a SAML assertion, OpenID assertion, >>>> Oauth assertion, Word document, or a love letter. >>>>=20 >>>> I dont think we should be building this sort of semantics into >>>> signature verification. >>>>=20 >>>> regards >>>>=20 >>>> David >>>>=20 >>>>=20 >>>> On 01/08/2012 03:11, Patrick Patterson wrote: >>>>> Hi Sean, >>>>>=20 >>>>> We're currently working the definition of "claim" that we're >>>>> going to use and have come up with: >>>>>=20 >>>>> "A signed claim is a set of attributes bound to a particular >>>>> subject using a digital signature in a way that relying parties >>>>> can make access or authorization decisions. >>>>>=20 >>>>> The presence of the claimSigning EKU indicates that a CA has >>>>> approved the certificate holder to sign claims for use within >>>>> a specific community of interest (e.g., a Federation) according >>>>> to the rules of that community. In other words, the holder of a >>>>> certificate that asserts the claimSigning EKU can bind >>>>> attributes to a subject for processing by a relying party " >>>>>=20 >>>>> What do people think about that? >>>>>=20 >>>>> We'll be further augmenting this definition with clearer >>>>> examples, but the original one for use by an IDP is still my >>>>> main target (Matt has his own which will be made clear in the >>>>> updated draft :). We'll also be addressing a bit why the >>>>> current status quo may not work for everyone (and may not >>>>> continue to work for anyone if all certificates issued by major >>>>> CAs that assert digSig and nonRep start having mandatory >>>>> populated EKU values). >>>>>=20 >>>>> I'll talk to Stefan tomorrow, but I'm leaning towards >>>>> withdrawing our spot on the Agenda tomorrow, until we can come >>>>> up with a Draft that addresses the concerns posted. (There's >>>>> also the matter that Matt's not here, and I've got to leave >>>>> before PKIX tomorrow :( ) >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Patrick. >>>>>=20 >>>>> On 2012-07-31, at 5:02 PM, Sean Turner wrote: >>>>>=20 >>>>>> I'm confused how a vague definition of a claim lines up with >>>>>> the need for a specific EKU (from Patrick's earlier >>>>>> message): >>>>>>=20 >>>>>> Unfortunately, due to recent events regarding the abuse of >>>>>> certificates asserting Key Usage values of digitalSignature >>>>>> and nonRepudiation, a number of policy authorities are >>>>>> mandating strict EKU values in all certificates asserting >>>>>> these key usage values, and mandating by policy that the >>>>>> anyEKU OID not be present. >>>>>>=20 >>>>>> You need a specific EKU to indicate you can sign a nebulous >>>>>> thing. What's the client going to check to know whether it's >>>>>> signing a claim or not? >>>>>>=20 >>>>>> spt >>>>>>=20 >>>>>> On 7/31/12 10:55 AM, Stefan Santesson wrote: >>>>>>> David, >>>>>>>=20 >>>>>>> A broad definition of "Claim" may be appropriate, but there >>>>>>> need to be one. Absent a definition, the EKU becomes >>>>>>> somewhat pointless as usage declaration. >>>>>>>=20 >>>>>>> /Stefan >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 12-07-31 10:37 AM, "David A. Cooper" >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Stefan, >>>>>>>>=20 >>>>>>>> Based on earlier discussions that I've had with some of >>>>>>>> the editors of this document, I believe that the reason >>>>>>>> the draft isn't entirely clear about what might >>>>>>>> constitute a "Claim" is that there is a desire for the >>>>>>>> definition of this OID to be somewhat generic so that in >>>>>>>> the future, when a key purpose OID is needed to indicate >>>>>>>> that the subject is authorized to sign "claims," this OID >>>>>>>> can be used rather than having to define a new OID for >>>>>>>> each specific application. >>>>>>>>=20 >>>>>>>> As an example, there are some signed CMS objects on PIV >>>>>>>> Cards. The CMS objects contain such things as biometric >>>>>>>> data of the cardholder and/or a unique identifier that >>>>>>>> has been assigned to the card. In FIPS 201, a key >>>>>>>> purpose OID was defined, id-PIV-content-signing, and >>>>>>>> there is a requirement that the signer of the CMS objects >>>>>>>> on the PIV Card must have a certificate that asserts the >>>>>>>> id-PIV-content-signing key purpose OID. When >>>>>>>> PIV-Interoperable cards were defined (similar to PIV >>>>>>>> Cards, but not issued by the U.S. Federal government), a >>>>>>>> new key purpose OID needed to be defined for the signers >>>>>>>> of the CMS objects on those cards, >>>>>>>> id-fpki-pivi-content-signing. It was noted that if >>>>>>>> there were a generic "claim signing" OID, then that OID >>>>>>>> could be used for both PIV and PIV-I Cards in addition to >>>>>>>> other cards that don't qualify as either PIV or PIV-I. >>>>>>>> We even received a comment on the current draft of FIPS >>>>>>>> 201 >>>>>>>> = (http://csrc.nist.gov/publications/drafts/fips201-2/draft-fips-20 >>>>>>>>=20 >>>>>>>>=20 > 1-2_comme >>>>>>>>=20 >>>>>>>>=20 >> nts_disposition-for-2011-draft.pdf) >>>>>>>> asking that FIPS 201 specify the use of the claimSigning >>>>>>>> OID being discussed in the PKIX WG rather than (or in >>>>>>>> addition to) the id-PIV-content-signing OID. >>>>>>>>=20 >>>>>>>> Dave >>>>>>>>=20 >>>>>>>> On 07/30/2012 03:04 PM, Stefan Santesson wrote: >>>>>>>>> I have a number of issues/questions regarding this >>>>>>>>> draft (still). >>>>>>>>>=20 >>>>>>>>> 1) Definition of "Claim" This EKU is said to state that >>>>>>>>> the subject is appropriate to sign "claims", but the >>>>>>>>> draft does not make an effort to define what a claim >>>>>>>>> is. It provides the examples SAML assertions and >>>>>>>>> Attribute Assertions, but does not state what else >>>>>>>>> could be regarded as a claim. Thus this EKU could be >>>>>>>>> used for virtually anything in absence of a clear >>>>>>>>> definition. >>>>>>>>>=20 >>>>>>>>> 2) Explain when this EKU is needed, relative to >>>>>>>>> metadata and pre-configured trust. The only examples >>>>>>>>> are SAML. In SAML it is common to either preconfigure >>>>>>>>> trust in assertion signers, removing the need for an >>>>>>>>> EKU, or by placing the cert in signed metadata also >>>>>>>>> removing the need for an EKU. What are the particular >>>>>>>>> use-case where you would neither use metadata, nor >>>>>>>>> pre-configured trust? A clarification of this would >>>>>>>>> help the reader to understand when this EKU is >>>>>>>>> appropriate. >>>>>>>>>=20 >>>>>>>>> 3) Discussion about assurance levels and policy OIDs. >>>>>>>>> When would you convey information about assurance level >>>>>>>>> of an assertion in a certificate policy of the signing >>>>>>>>> certificate? Information about assurance level is >>>>>>>>> provided in SAML requests and responses. Information >>>>>>>>> about what assurance level the IdP is trusted to >>>>>>>>> provide (certified for) is normally provided in signed >>>>>>>>> metadata (SAML) or may be implicit in the case of >>>>>>>>> pre-configured trust. When would it be appropriate to >>>>>>>>> solve this using cert policies? Is there any deployed >>>>>>>>> examples of this? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> /Stefan >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ pkix >>>>>>> mailing list pkix@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>>>=20 >>>>>> _______________________________________________ pkix mailing >>>>>> list pkix@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>=20 >>>>> --- Patrick Patterson President and Chief PKI Architect >>>>> Carillon Information Security Inc. http://www.carillon.ca >>>>>=20 >>>>> tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 >>>>> 9559 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ pkix mailing >>>>> list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>>>>=20 >>>=20 >>> --- Patrick Patterson President and Chief PKI Architect Carillon >>> Information Security Inc. http://www.carillon.ca >>>=20 >>> tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >> _______________________________________________ pkix mailing list >> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>=20 --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 From SChokhani@cygnacom.com Wed Aug 1 14:02:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95C021F893D for ; Wed, 1 Aug 2012 14:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nZtwGxM+MYH for ; Wed, 1 Aug 2012 14:02:31 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0052821F893B for ; Wed, 1 Aug 2012 14:02:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,696,1336363200"; d="scan'208";a="5784576" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 01 Aug 2012 17:02:30 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 1 Aug 2012 17:02:30 -0400 From: Santosh Chokhani To: "mrex@sap.com" Date: Wed, 1 Aug 2012 17:02:29 -0400 Thread-Topic: [pkix] new text for 5280bis, Section 3.2 Thread-Index: Ac1wI3Ux9hiYBc/hQiucZALzkphFXwABTM4g Message-ID: References: <20120801202242.50D1E1A10B@ld9781.wdf.sap.corp> In-Reply-To: <20120801202242.50D1E1A10B@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] new text for 5280bis, Section 3.2 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:02:32 -0000 Martin, I do not follow what you are saying. Are you saying what Steve drafted is fine or my edits are fine or neither i= s fine? -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Wednesday, August 01, 2012 4:23 PM To: Santosh Chokhani Cc: Stephen Kent; pkix Subject: Re: [pkix] new text for 5280bis, Section 3.2 Santosh Chokhani wrote: > > How about the following: >=20 > Consistent with Section 3.4.61 of X.509 (11/2008) we note that use of=20 > self-issued certificates and self-signed certificates when issued by=20 > entities other than CAs are outside the scope of this specification. > Thus, for example, a web server or client might generate a self-signed=20 > certificate to identity itself. These certificates, and how a relying=20 > party uses them to authenticate asserted identities, are both outside=20 > the scope of RFC 5280. OT: >From the parallel discussion thread about OCSP 2560bis, I noticed a throrou= ghly confusing example in Appendix E.3 Locally Trusted OCSP Responder at th= e end of -04 document: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-04#page-42 which uses a self-signed certificate of a non-CA entity. This is outside of PKIX/rfc5280 and an option not listed under 2.3.5.2: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-04#section-2.3.5.2 and looks to _me_ like a bad idea in general. -Martin From mrex@sap.com Wed Aug 1 14:20:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D8611E835C for ; Wed, 1 Aug 2012 14:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.194 X-Spam-Level: X-Spam-Status: No, score=-10.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdvSNfgL-AQB for ; Wed, 1 Aug 2012 14:20:22 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 31A2411E834A for ; Wed, 1 Aug 2012 14:20:16 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q71LKAQA015427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Aug 2012 23:20:15 +0200 (MEST) In-Reply-To: <50193573.1090303@nist.gov> To: "David A. Cooper" Date: Wed, 1 Aug 2012 23:20:09 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120801212009.D99891A10B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] 2560bis (essay version) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:20:23 -0000 David A. Cooper wrote: > > Please read > http://www.ietf.org/mail-archive/web/pkix/current/msg27687.html for an > example of the confusion that the text in RFC 2560 is causing. This is > not about making changes to the protocol and then trying to achieve > greater adoption of those changes, it is about making the document > sufficiently clear and unambiguous that problems like the one described > in that message can be avoided in the future. I haven't fully read through this, but it appears to be quite related to my complaint about Appendix E of the -04 document to be lacking requirements on inclusion of which particular certs in the OCSP response in order to provide a basis for interop. Without such requirements about which certs must be present in the OCSP response, interop will remain a lucky coincidence rather than a result of conscious design decisions. And as an implementor, I would limit my OCSP to exactly two cases: (1) certificate signer key also signed the OCSP response (2) certificate signer key also signed an OCSP responder cert, and this OCSP responder cert MUST be included in the OCSP response. > > In this message, you are again asking for changes to be made. For > example you said: > > What seems to be badly lacking in Appendix E of -04 is the requirements > > of which certs MUST be included in the OCSP response for each of the > > example CA/OCSP architecture/hierarchy, except for Figure 1 (where > > no cert is necessary). > > I was given a very strict mandate to not make any changes to OCSP. Can > you show me where this "MUST" requirement appears in RFC 2560? If not, > then how could I include such a "MUST" requirement in 2560bis without > breaking my promise not to make any changes to the protocol. This > proposed change may be a good idea, but that doesn't mean it's not a change. First, the rest of my reply was under the stated premise: = = This sounds like you're asking for _changing_ the existing protocol = by publishing a new spec with different or additional requirements. and secondly, I'm against requiring OCSP clients to support fancy PKI models. However the complete lack of details what needs to be included in an OCSP response in order to provide a basis for interop is a DEFECT of rfc2560. I would be perfectly OK with augmenting the existing spec with something like "In order to provide reliable interoperability on this protocol options, the following additional requirements are necessary, that are not part of rfc2560 (but might have been obvious implications for some implementors anyhow". If you approach rfc2560 from the viewpoint of formal correctness proofing, you will immediately notice which protocol options are underspecified and where you will encounter interop problems with implementers who do not read a spec and create an implementation with any kind of formal correctness in mind (i.e. planned and predictable behaviour in unknown future usage scenarios). > > You also say that "There really ought to be a requirement that > implementations (of CA and OCSP software) MUST support short-lived OCSP > signer certs...." Again, that may be a good idea, but can you find that > requirement in RFC 2560? If not, then wouldn't including such a > requirement in 2560bis be a change? Same as above. > > The final paragraph in your message proposes reordering the checks in > Section 2.3.6. However, the checks in Section 2.3.6 are listed in the > same order as they appear in Section 3.2 of RFC 2560. While one could > certainly reorder them without changing the protocol since the text does > not specify that the checks need to be performed in the order they are > listed, it would seem that reordering them would be inconsistent with > the approach that you are advocating of "doing minimal changes to the > original document." rfcdiff visualizes this as newly added text: http://tools.ietf.org/rfcdiff?url1=rfc2560.txt&url2=draft-ietf-pkix-rfc2560bis-04.txt ...which is one of the reasons that I'm violently opposed to completely rearrange the document structure in the fasion of -04 Concerning the same info in section of rfc2560 section 3.2 a clarifying text that the ordering in the enumeration is not normative, and it might be sensible to perform the public key signature verification at the end, rather than as 2nd check, because it is likely the most "expensive" operation and one should avoid making public key crypto operations with public keys before it has been established that these keys are trustworthy. > > You also misrepresent RFC 5280 in your message. RFC 5280 very clearly > allows CAs to sign CRLs with a different key than was used to sign the > certificates covered by the CRL, and notes that it may be necessary for > a relying party to build a separate certification path for the > certificate needed to verify the signature on the CRL. Quoting from rfc5280, section 5.1.1.3 http://tools.ietf.org/html/rfc5280#section-5.1.1.3 The use of separate CA certificates for validation of certificate signatures and CRL signatures can offer improved security characteristics; however, it imposes a burden on applications, and it might limit interoperability. Many applications construct a certification path, and then validate the certification path (Section 6). CRL checking in turn requires a separate certification path to be constructed and validated for the CA's CRL *> signature validation certificate. Applications that perform CRL *> checking MUST support certification path validation when certificates *> and CRLs are digitally signed with the same CA private key. These applications SHOULD support certification path validation when certificates and CRLs are digitally signed with different CA private keys. rfc5280 is pretty explicit that support for CRLs that are not signed by the same CA key that signed the certificate is OPTIONAL, because MINIMUM REQUIREMENT RPs will likely not support it. Keep in mind that CRLs, in contrast to OCSP, lack a standardized carry-on container for CRL signer certificates. Keep also in mind, that construction(!) of a certificate path is explicitly outside of the scope of rfc5280. Which more-or-less means that all options described in rfc5280 that require certificate path construction are implicitly outside the scope of rfc5280 as well (and very likely missing in minimum requirement RPs): http://tools.ietf.org/html/rfc5280#page-73 The primary goal of path validation is to verify the binding between a subject distinguished name or a subject alternative name and subject public key, as represented in the target certificate, based on the public key of the trust anchor. In most cases, the target certificate will be an end entity certificate, but the target certificate may be a CA certificate as long as the subject public key is to be used for a purpose other than verifying the signature on a public key certificate. Verifying the binding between the name and subject public key requires obtaining a sequence of certificates that *> support that binding. The procedure performed to obtain this *> sequence of certificates is outside the scope of this specification. > > As for OCSP, contrary to your assertion, relying parties are *NOT* > required to be able to validate responses if the response > (or the responder's certificate) was signed with a different key > than the target certificate. That is a misunderstanding. I'm perfectly aware and OK with this. > > I cannot find a single statement in RFC 2560 that states > that conforming applications MUST be able to validate such responses, > and so there is no such statement in 2560bis either. What is lacking in RFC2560, and should be added in rfc2560bis is that when using a different OCSP signer cert, then the OCSP server MUST include all certs that will be necessary for processing this OCSP response *within* the OCSP response. In general, this also means that the examples in Figure 7, Figure 8 and Figure 9 of -04 are incorrect, because in general a cross-cert between the cert-signing CA cert and the OCSP-responder signing CA cert will be necessary, unless the OCSP request contains an unambiguous proof that the OCSP client is in posession of the rootCA cert from Figures 7, 8, 9 -Martin From mrex@sap.com Wed Aug 1 14:33:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E808B11E8183 for ; Wed, 1 Aug 2012 14:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.196 X-Spam-Level: X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pGnvUxxackF for ; Wed, 1 Aug 2012 14:33:54 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1572711E817B for ; Wed, 1 Aug 2012 14:33:53 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q71LXe3j016221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Aug 2012 23:33:45 +0200 (MEST) In-Reply-To: To: Santosh Chokhani Date: Wed, 1 Aug 2012 23:33:40 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120801213340.4500D1A10B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] new text for 5280bis, Section 3.2 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:33:55 -0000 Santosh Chokhani wrote: > Martin, > > I do not follow what you are saying. > > Are you saying what Steve drafted is fine or my edits are fine or neither is fine? I'm sorry for the confusion. The text works for me (the leading text about BasicConstraints was confusing, but is not longer part of your proposal). I intended to indicate with "OT:" ("off-topic") that this comment was not about the proposed text itself (topic of this discussion thread) but related to it. Primarily I wanted to point out that the example usage scenario for a local OCSP responder, that is depicted in Appendix E.3 of the rfc2560bis-04 document, a self-signed cert that is issued by a non-CA is used. To me it looks very odd that the only usage scenario described for a local OCSP responder is implicitly out-of-scope for rfc5280 and will be explicitly out-of-scope for rfc5280bis. -Martin > > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Wednesday, August 01, 2012 4:23 PM > To: Santosh Chokhani > Cc: Stephen Kent; pkix > Subject: Re: [pkix] new text for 5280bis, Section 3.2 > > Santosh Chokhani wrote: > > > > How about the following: > > > > Consistent with Section 3.4.61 of X.509 (11/2008) we note that use of > > self-issued certificates and self-signed certificates when issued by > > entities other than CAs are outside the scope of this specification. > > Thus, for example, a web server or client might generate a self-signed > > certificate to identity itself. These certificates, and how a relying > > party uses them to authenticate asserted identities, are both outside > > the scope of RFC 5280. > > OT: > > >From the parallel discussion thread about OCSP 2560bis, I noticed a throroughly confusing example in Appendix E.3 Locally Trusted OCSP Responder at the end of -04 document: > > http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-04#page-42 > > which uses a self-signed certificate of a non-CA entity. > > This is outside of PKIX/rfc5280 and an option not listed under 2.3.5.2: > > http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-04#section-2.3.5.2 > > and looks to _me_ like a bad idea in general. > > > -Martin From trevorf@exchange.microsoft.com Wed Aug 1 15:08:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B5611E8376 for ; Wed, 1 Aug 2012 15:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY5tCMKDY7cr for ; Wed, 1 Aug 2012 15:08:57 -0700 (PDT) Received: from na01b.map.o365filtering.com (sn2c-ob.o365filtering.com [157.55.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id D3ECA11E836D for ; Wed, 1 Aug 2012 15:08:55 -0700 (PDT) Received: from BY2SR01CA101.namsdf01.sdf.exchangelabs.com (10.255.93.146) by BY2SR01MB607.namsdf01.sdf.exchangelabs.com (10.255.93.166) with Microsoft SMTP Server (TLS) id 15.0.466.11; Wed, 1 Aug 2012 21:43:16 +0000 Received: from SN2FFOFD003.ffo.gbl (157.55.158.27) by BY2SR01CA101.namsdf01.sdf.exchangelabs.com (10.255.93.146) with Microsoft SMTP Server (TLS) id 15.0.485.4; Wed, 1 Aug 2012 21:43:16 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.17) by SN2FFOFD003.mail.o365filtering.com (10.111.201.40) with Microsoft SMTP Server (TLS) id 15.0.485.0; Wed, 1 Aug 2012 21:43:16 +0000 Received: from DFM-TK5MBX15-03.exchange.corp.microsoft.com (157.54.110.22) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.3.71.0; Wed, 1 Aug 2012 14:40:47 -0700 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DFM-TK5MBX15-03.exchange.corp.microsoft.com (157.54.110.22) with Microsoft SMTP Server (TLS) id 15.0.466.15; Wed, 1 Aug 2012 14:40:45 -0700 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.03.0071.000; Wed, 1 Aug 2012 14:40:44 -0700 From: Trevor Freeman To: David Chadwick Thread-Topic: [pkix] Updated claimSigning EKU Internet Draft Thread-Index: AQHNaz6Da2j+4WxoJ0afqzBXvMsVc5dCqzIAgAF594CAAAUVAIAANCkAgABWS4CAAJsrgIAAJ1EAgAAihAD//6m10IAApaiA//+bqAA= Date: Wed, 1 Aug 2012 21:40:41 +0000 Message-ID: References: <501847DC.5030509@ieca.com> <50191269.8090000@kent.ac.uk> <5E5299BC-836C-4BD3-A0EA-904B5EF3D8E2@carillon.ca> <50195058.9090907@kent.ac.uk> <501992EB.5030501@kent.ac.uk> In-Reply-To: <501992EB.5030501@kent.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.94.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.17; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424002)(377454001)(51704002)(45074001)(13464001)(24454001)(479174001)(407274001)(42186003)(16406001)(33656001)(31966006); DIR:INB; ; LANG:en; X-Forefront-PRVS: 0560A2214D X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Cc: Patrick Patterson , "pkix@ietf.org PKIX" Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:08:59 -0000 Hi David, The message I hear loud and clear from organization is their pain due to es= calating management cost because so many technologies are management stove = pipes. So while most of us are trying to find ways to make management share= d across applications, hear you are suggesting this is a good thing. If it looks like a pkix certificate, smells like a pkix certificate it shou= ld be managed like a pkix certificate.=20 Trevor -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk]=20 Sent: Wednesday, August 01, 2012 1:35 PM To: Trevor Freeman Cc: Patrick Patterson; pkix@ietf.org PKIX Subject: Re: [pkix] Updated claimSigning EKU Internet Draft Hi Trevor there is one big difference in all these cases your mention and that of a P= MI claim which I mention, namely, the RPs are either all applications (sign= ed code, signed documents) or PKI components (revocation) that are using th= e PKI to validate its signed documents. Thus the PKI is the *only* security component the RP is relying on, whilst in the case of valid= ating a PMI claim, the PMI is actually part of the security infrastructure = itself (on a par with the PKI). Thus the PMI does not need to rely on the P= KI to the same extent as the other components. It is fully capable of valid= ating its own trust chains. The PMI forms a parallel infrastructure to the = PKI. regards David On 01/08/2012 18:50, Trevor Freeman wrote: > David, > > I am somewhat baffled by your comment. There is a long precedence for > refining the sign semantics of the key used extension via the eku > extension to express sign what. We have signed code, signed > documents, signed revocation responses eku purposes. The whole > purpose of the EKU extension was to enable this kind of expression. > The RP absolutely understands if it is processing claims so can > filter based on EKU. We should not be inventing new semantics for > different kinds of signing. > > Trevor -----Original Message----- From: pkix-bounces@ietf.org > [mailto:pkix-bounces@ietf.org] On Behalf Of David Chadwick Sent: > Wednesday, August 01, 2012 8:51 AM To: Patrick Patterson Cc: > pkix@ietf.org PKIX Subject: Re: [pkix] Updated claimSigning EKU > Internet Draft > > Hi Patrick > > I am talking from the perspective of the RP which, in the case of > SAML, would be the SAML SP, which has received a SAML assertion which > it needs to verify. > > On 01/08/2012 14:47, Patrick Patterson wrote: >> Hi David, >> >> I'm not at all sure what you are talking about - I've never seen a >> world where an RP gives anything to the PKI to verify - it usually >> (when it is well behaved) extracts the certificate (after making >> sure that the public key in the cert is the same that was used to >> sign the message) and does RFC5280 Section 6 validation on it, or >> at least makes sure this Certificate chains to a Trust Anchor that >> it has pre-configured. > > In my opinion this is part of the PKI validation, not the PMI > validation (section 6 is entitled certification path validation). The > PKI roots of trust are configured into the PKI, not the PMI. The PMI > would only have one or more PKI roots of trust configured into it, if > it did not know who its trusted IDPs were, and was relying on the PKI > to tell it. > > This is all done on the RP itself. > > the RP is the SAML IDP in the case of SAML assertions. It is relying > on the PKI to validate the signatures on the signed messages (SAML > assertions) that it receives. > > The RP knows the >> semantics of the message that it has, and presumably (in the case >> of SAML) knows who the authorised IDPs are (which may include, in >> this case, checking to see if the claimSigning EKU is present). > > If the RP already knows who the trusted IDPs are, then there is no > point in having the EKU field. All that is important is that the > assertion is signed by the IDP, regardless of which key or > certificate it used. The SAML SP should be insulated from the IDP > migrating between keys and certificates - let the PKI component take > care of this. I know that today's implementations pass around > certificates in meta-data, but I regard this is as deficiency in > trust validation. > > regards > > David > > >> >> I'm not asking for, or saying anything about signature semantics - >> Stefan and Sean wanted a definition of a claim to be used when >> asserting the "claimSigning" EKU, and I gave it to them. >> >> Cheers, >> >> Patrick. >> >> On 2012-08-01, at 7:26 AM, David Chadwick wrote: >> >>> Hi Patrick >>> >>> one problem see with this is as follows >>> >>> The RP typically gives a binary blob to the PKI and asks it to >>> validate the signature on the binary blob. The PKI has no >>> knowledge about the semantic content of this blob. So it cannot >>> tell the difference between a SAML assertion, OpenID assertion, >>> Oauth assertion, Word document, or a love letter. >>> >>> I dont think we should be building this sort of semantics into >>> signature verification. >>> >>> regards >>> >>> David >>> >>> >>> On 01/08/2012 03:11, Patrick Patterson wrote: >>>> Hi Sean, >>>> >>>> We're currently working the definition of "claim" that we're >>>> going to use and have come up with: >>>> >>>> "A signed claim is a set of attributes bound to a particular >>>> subject using a digital signature in a way that relying parties >>>> can make access or authorization decisions. >>>> >>>> The presence of the claimSigning EKU indicates that a CA has >>>> approved the certificate holder to sign claims for use within >>>> a specific community of interest (e.g., a Federation) according >>>> to the rules of that community. In other words, the holder of a >>>> certificate that asserts the claimSigning EKU can bind >>>> attributes to a subject for processing by a relying party " >>>> >>>> What do people think about that? >>>> >>>> We'll be further augmenting this definition with clearer >>>> examples, but the original one for use by an IDP is still my >>>> main target (Matt has his own which will be made clear in the >>>> updated draft :). We'll also be addressing a bit why the >>>> current status quo may not work for everyone (and may not >>>> continue to work for anyone if all certificates issued by major >>>> CAs that assert digSig and nonRep start having mandatory >>>> populated EKU values). >>>> >>>> I'll talk to Stefan tomorrow, but I'm leaning towards >>>> withdrawing our spot on the Agenda tomorrow, until we can come >>>> up with a Draft that addresses the concerns posted. (There's >>>> also the matter that Matt's not here, and I've got to leave >>>> before PKIX tomorrow :( ) >>>> >>>> Cheers, >>>> >>>> Patrick. >>>> >>>> On 2012-07-31, at 5:02 PM, Sean Turner wrote: >>>> >>>>> I'm confused how a vague definition of a claim lines up with >>>>> the need for a specific EKU (from Patrick's earlier >>>>> message): >>>>> >>>>> Unfortunately, due to recent events regarding the abuse of >>>>> certificates asserting Key Usage values of digitalSignature >>>>> and nonRepudiation, a number of policy authorities are >>>>> mandating strict EKU values in all certificates asserting >>>>> these key usage values, and mandating by policy that the >>>>> anyEKU OID not be present. >>>>> >>>>> You need a specific EKU to indicate you can sign a nebulous >>>>> thing. What's the client going to check to know whether it's >>>>> signing a claim or not? >>>>> >>>>> spt >>>>> >>>>> On 7/31/12 10:55 AM, Stefan Santesson wrote: >>>>>> David, >>>>>> >>>>>> A broad definition of "Claim" may be appropriate, but there >>>>>> need to be one. Absent a definition, the EKU becomes >>>>>> somewhat pointless as usage declaration. >>>>>> >>>>>> /Stefan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 12-07-31 10:37 AM, "David A. Cooper" >>>>>> wrote: >>>>>> >>>>>>> Stefan, >>>>>>> >>>>>>> Based on earlier discussions that I've had with some of >>>>>>> the editors of this document, I believe that the reason >>>>>>> the draft isn't entirely clear about what might >>>>>>> constitute a "Claim" is that there is a desire for the >>>>>>> definition of this OID to be somewhat generic so that in >>>>>>> the future, when a key purpose OID is needed to indicate >>>>>>> that the subject is authorized to sign "claims," this OID >>>>>>> can be used rather than having to define a new OID for >>>>>>> each specific application. >>>>>>> >>>>>>> As an example, there are some signed CMS objects on PIV >>>>>>> Cards. The CMS objects contain such things as biometric >>>>>>> data of the cardholder and/or a unique identifier that >>>>>>> has been assigned to the card. In FIPS 201, a key >>>>>>> purpose OID was defined, id-PIV-content-signing, and >>>>>>> there is a requirement that the signer of the CMS objects >>>>>>> on the PIV Card must have a certificate that asserts the >>>>>>> id-PIV-content-signing key purpose OID. When >>>>>>> PIV-Interoperable cards were defined (similar to PIV >>>>>>> Cards, but not issued by the U.S. Federal government), a >>>>>>> new key purpose OID needed to be defined for the signers >>>>>>> of the CMS objects on those cards, >>>>>>> id-fpki-pivi-content-signing. It was noted that if >>>>>>> there were a generic "claim signing" OID, then that OID >>>>>>> could be used for both PIV and PIV-I Cards in addition to >>>>>>> other cards that don't qualify as either PIV or PIV-I. >>>>>>> We even received a comment on the current draft of FIPS >>>>>>> 201 >>>>>>> (http://csrc.nist.gov/publications/drafts/fips201-2/draft-fips-20 >>>>>>> >>>>>>> 1-2_comme >>>>>>> >>>>>>> > nts_disposition-for-2011-draft.pdf) >>>>>>> asking that FIPS 201 specify the use of the claimSigning >>>>>>> OID being discussed in the PKIX WG rather than (or in >>>>>>> addition to) the id-PIV-content-signing OID. >>>>>>> >>>>>>> Dave >>>>>>> >>>>>>> On 07/30/2012 03:04 PM, Stefan Santesson wrote: >>>>>>>> I have a number of issues/questions regarding this >>>>>>>> draft (still). >>>>>>>> >>>>>>>> 1) Definition of "Claim" This EKU is said to state that >>>>>>>> the subject is appropriate to sign "claims", but the >>>>>>>> draft does not make an effort to define what a claim >>>>>>>> is. It provides the examples SAML assertions and >>>>>>>> Attribute Assertions, but does not state what else >>>>>>>> could be regarded as a claim. Thus this EKU could be >>>>>>>> used for virtually anything in absence of a clear >>>>>>>> definition. >>>>>>>> >>>>>>>> 2) Explain when this EKU is needed, relative to >>>>>>>> metadata and pre-configured trust. The only examples >>>>>>>> are SAML. In SAML it is common to either preconfigure >>>>>>>> trust in assertion signers, removing the need for an >>>>>>>> EKU, or by placing the cert in signed metadata also >>>>>>>> removing the need for an EKU. What are the particular >>>>>>>> use-case where you would neither use metadata, nor >>>>>>>> pre-configured trust? A clarification of this would >>>>>>>> help the reader to understand when this EKU is >>>>>>>> appropriate. >>>>>>>> >>>>>>>> 3) Discussion about assurance levels and policy OIDs. >>>>>>>> When would you convey information about assurance level >>>>>>>> of an assertion in a certificate policy of the signing >>>>>>>> certificate? Information about assurance level is >>>>>>>> provided in SAML requests and responses. Information >>>>>>>> about what assurance level the IdP is trusted to >>>>>>>> provide (certified for) is normally provided in signed >>>>>>>> metadata (SAML) or may be implicit in the case of >>>>>>>> pre-configured trust. When would it be appropriate to >>>>>>>> solve this using cert policies? Is there any deployed >>>>>>>> examples of this? >>>>>>>> >>>>>>>> >>>>>>>> /Stefan >>>>>> >>>>>> >>>>>> _______________________________________________ pkix >>>>>> mailing list pkix@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>> >>>>> _______________________________________________ pkix mailing >>>>> list pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>>> --- Patrick Patterson President and Chief PKI Architect >>>> Carillon Information Security Inc. http://www.carillon.ca >>>> >>>> tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 >>>> 9559 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ pkix mailing >>>> list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>>> >> >> --- Patrick Patterson President and Chief PKI Architect Carillon >> Information Security Inc. http://www.carillon.ca >> >> tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 >> >> >> >> >> > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix > From peter@akayla.com Wed Aug 1 15:27:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2292711E83E0 for ; Wed, 1 Aug 2012 15:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnLY03CBIZHd for ; Wed, 1 Aug 2012 15:27:07 -0700 (PDT) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by ietfa.amsl.com (Postfix) with SMTP id 2A64911E8399 for ; Wed, 1 Aug 2012 15:27:07 -0700 (PDT) Received: (qmail 5703 invoked from network); 1 Aug 2012 22:27:02 -0000 Received: from unknown (130.129.86.230) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 01 Aug 2012 22:27:01 -0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Wed, 01 Aug 2012 15:26:53 -0700 From: Peter Yee To: Stephen Kent , pkix Message-ID: Thread-Topic: [pkix] 2560bis In-Reply-To: <50156F44.6010305@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:27:08 -0000 A as well. -Peter On 7/29/12 10:13 AM, "Stephen Kent" wrote: >Folks, > >Recent messages exchanges point to significant disagreement about the >future direction >for this doc. At the March meeting Stefan presented a proposal for how >to move >ahead, as outlined in his slides. As noted in the minutes, the audience >(at the mic) >included one indication of support for this streamlined approach, and >one expression >of concern. Not a lot of interest. > >Work on this doc has dragged on for 2 years now. In October of 2011 >Santosh argued that >version -04 of the doc was, in his opinion, a step backwards, adding >more confusion to >RFC 2560 vs. clarifying it. Stefan agreed (in a message in March of >2012), and >thus he created the current, stripped-down version of the doc (-05) >which was published >recently. > >Given the mixed response to this version, it's not clear that the WG >members who are interested >in OCSP clarifications are in agreement on how to proceed. > >So, let's begin a straw poll on the topic. Here are the options I am >offering: > > A - continue to work with the -05 version as the basis for an RFC > B - revert to the -04 version as the basis for an RFC > C - don't publish a clarifications document for OCSP > D - the respondent volunteers to work on a new version of 2560bis > >Please send your replies to the list starting now. The straw poll will >close >in two weeks, on August 12. While there are many other, legitimate >comments one could >offer, I am interested only in replies to this multiple choice straw >poll (i.e., no >essay replies :-) ) > >Thanks, > >Steve > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix > From mrex@sap.com Wed Aug 1 15:37:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FAA21F889F for ; Wed, 1 Aug 2012 15:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnOkQRkzMTBq for ; Wed, 1 Aug 2012 15:37:21 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 53FC021F889D for ; Wed, 1 Aug 2012 15:37:21 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q71MbKsm028187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Aug 2012 00:37:20 +0200 (MEST) To: pkix@ietf.org Date: Thu, 2 Aug 2012 00:37:20 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120801223720.188A31A10B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Subject: [pkix] rfc5280-clarifications, self-signed non-CA cert X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:37:22 -0000 As it was just mentioned in the meeting. RFC 5280 is referencing X.509 2005/08 rather than X.509 2008/11, so the comment about self-signed non-CA certs is: X.509 2005/08 3.3.56 self-signed certificate X.509 2008/11 3.4.61 self-signed certificate I'm sorry for the confusion. -Martin From d.w.chadwick@kent.ac.uk Wed Aug 1 15:40:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB7811E80BA for ; Wed, 1 Aug 2012 15:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awN13gYJFqSb for ; Wed, 1 Aug 2012 15:40:28 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id B164B11E80D9 for ; Wed, 1 Aug 2012 15:40:22 -0700 (PDT) Received: from mx0.kent.ac.uk ([129.12.21.32]) by mx1.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwhaX-0003kM-DA; Wed, 01 Aug 2012 23:40:21 +0100 Received: from [31.185.215.137] (helo=[192.168.1.38]) by mx0.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwhaW-0001XW-Ia; Wed, 01 Aug 2012 23:40:21 +0100 Message-ID: <5019B055.60809@kent.ac.uk> Date: Wed, 01 Aug 2012 23:40:21 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Patrick Patterson References: <501847DC.5030509@ieca.com> <50191269.8090000@kent.ac.uk> <5E5299BC-836C-4BD3-A0EA-904B5EF3D8E2@carillon.ca> <50195058.9090907@kent.ac.uk> <501992EB.5030501@kent.ac.uk> <0BEB4006-5762-42A5-BEC8-24F79A4184CF@carillon.ca> In-Reply-To: <0BEB4006-5762-42A5-BEC8-24F79A4184CF@carillon.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:40:31 -0000 Hi Patrick On 01/08/2012 21:59, Patrick Patterson wrote: > Hello David, > > I think that your assumption only works in the case where the PMI > operates their own CA (that signs only Metadata and/or IDP > certificates). Absolutely not. PMIs should always be designed to work with general purpose PKIs and software (e.g. we use bouncy castle in our PMI). > > In a couple of cases that I am aware of, the same CA that issues > Identity Certificates, general Purpose Device Certificates, there is > a desire issue IDP Certs, and distinguish these from general purpose > Device certificates. "there is a desire" by whom? The CA operator? The federation operator? The RP/SP? The PMI? > > Furthermore, IDPs may be part of a dynamic Federation (it is > sufficient to be part of the same PKI Community - we're treating > Attribute Assurance separately), and therefore there IS no metadata. Fine, I like that model much better. Metadata harks back to pre-DNS days when sites used to be email the name-address mappings nightly. You would have thought that federations would have learnt from that experience that using metadata does not scale well. (The UK Access Federation has belatedly found this out). > Consequently, the PMI and the PKI may be part of the same Trust > Infrastructure, and therefore are not considered independent. They are always independent. Just as authn is separate from authz, trust in who issues claims is independent from who issues PKCs. Mixing them together is a big mistake. (this does not mean that the same entity cannot be trusted to do both, but logically they are separate roles) regards David > > There are many models for Federation that are emerging, and we need > to have a way to support these. > > Cheers, > > Patrick. > > On 2012-08-01, at 4:34 PM, David Chadwick wrote: > >> Hi Trevor >> >> there is one big difference in all these cases your mention and >> that of a PMI claim which I mention, namely, the RPs are either all >> applications (signed code, signed documents) or PKI components >> (revocation) that are using the PKI to validate its signed >> documents. Thus the PKI is the *only* security component the RP is >> relying on, whilst in the case of validating a PMI claim, the PMI >> is actually part of the security infrastructure itself (on a par >> with the PKI). Thus the PMI does not need to rely on the PKI to the >> same extent as the other components. It is fully capable of >> validating its own trust chains. The PMI forms a parallel >> infrastructure to the PKI. >> >> regards >> >> David >> >> On 01/08/2012 18:50, Trevor Freeman wrote: >>> David, >>> >>> I am somewhat baffled by your comment. There is a long precedence >>> for refining the sign semantics of the key used extension via the >>> eku extension to express sign what. We have signed code, signed >>> documents, signed revocation responses eku purposes. The whole >>> purpose of the EKU extension was to enable this kind of >>> expression. The RP absolutely understands if it is processing >>> claims so can filter based on EKU. We should not be inventing new >>> semantics for different kinds of signing. >>> >>> Trevor -----Original Message----- From: pkix-bounces@ietf.org >>> [mailto:pkix-bounces@ietf.org] On Behalf Of David Chadwick Sent: >>> Wednesday, August 01, 2012 8:51 AM To: Patrick Patterson Cc: >>> pkix@ietf.org PKIX Subject: Re: [pkix] Updated claimSigning EKU >>> Internet Draft >>> >>> Hi Patrick >>> >>> I am talking from the perspective of the RP which, in the case >>> of SAML, would be the SAML SP, which has received a SAML >>> assertion which it needs to verify. >>> >>> On 01/08/2012 14:47, Patrick Patterson wrote: >>>> Hi David, >>>> >>>> I'm not at all sure what you are talking about - I've never >>>> seen a world where an RP gives anything to the PKI to verify - >>>> it usually (when it is well behaved) extracts the certificate >>>> (after making sure that the public key in the cert is the same >>>> that was used to sign the message) and does RFC5280 Section 6 >>>> validation on it, or at least makes sure this Certificate >>>> chains to a Trust Anchor that it has pre-configured. >>> >>> In my opinion this is part of the PKI validation, not the PMI >>> validation (section 6 is entitled certification path validation). >>> The PKI roots of trust are configured into the PKI, not the PMI. >>> The PMI would only have one or more PKI roots of trust configured >>> into it, if it did not know who its trusted IDPs were, and was >>> relying on the PKI to tell it. >>> >>> This is all done on the RP itself. >>> >>> the RP is the SAML IDP in the case of SAML assertions. It is >>> relying on the PKI to validate the signatures on the signed >>> messages (SAML assertions) that it receives. >>> >>> The RP knows the >>>> semantics of the message that it has, and presumably (in the >>>> case of SAML) knows who the authorised IDPs are (which may >>>> include, in this case, checking to see if the claimSigning EKU >>>> is present). >>> >>> If the RP already knows who the trusted IDPs are, then there is >>> no point in having the EKU field. All that is important is that >>> the assertion is signed by the IDP, regardless of which key or >>> certificate it used. The SAML SP should be insulated from the >>> IDP migrating between keys and certificates - let the PKI >>> component take care of this. I know that today's implementations >>> pass around certificates in meta-data, but I regard this is as >>> deficiency in trust validation. >>> >>> regards >>> >>> David >>> >>> >>>> >>>> I'm not asking for, or saying anything about signature >>>> semantics - Stefan and Sean wanted a definition of a claim to >>>> be used when asserting the "claimSigning" EKU, and I gave it to >>>> them. >>>> >>>> Cheers, >>>> >>>> Patrick. >>>> >>>> On 2012-08-01, at 7:26 AM, David Chadwick wrote: >>>> >>>>> Hi Patrick >>>>> >>>>> one problem see with this is as follows >>>>> >>>>> The RP typically gives a binary blob to the PKI and asks it >>>>> to validate the signature on the binary blob. The PKI has no >>>>> knowledge about the semantic content of this blob. So it >>>>> cannot tell the difference between a SAML assertion, OpenID >>>>> assertion, Oauth assertion, Word document, or a love letter. >>>>> >>>>> I dont think we should be building this sort of semantics >>>>> into signature verification. >>>>> >>>>> regards >>>>> >>>>> David >>>>> >>>>> >>>>> On 01/08/2012 03:11, Patrick Patterson wrote: >>>>>> Hi Sean, >>>>>> >>>>>> We're currently working the definition of "claim" that >>>>>> we're going to use and have come up with: >>>>>> >>>>>> "A signed claim is a set of attributes bound to a >>>>>> particular subject using a digital signature in a way that >>>>>> relying parties can make access or authorization >>>>>> decisions. >>>>>> >>>>>> The presence of the claimSigning EKU indicates that a CA >>>>>> has approved the certificate holder to sign claims for use >>>>>> within a specific community of interest (e.g., a >>>>>> Federation) according to the rules of that community. In >>>>>> other words, the holder of a certificate that asserts the >>>>>> claimSigning EKU can bind attributes to a subject for >>>>>> processing by a relying party " >>>>>> >>>>>> What do people think about that? >>>>>> >>>>>> We'll be further augmenting this definition with clearer >>>>>> examples, but the original one for use by an IDP is still >>>>>> my main target (Matt has his own which will be made clear >>>>>> in the updated draft :). We'll also be addressing a bit why >>>>>> the current status quo may not work for everyone (and may >>>>>> not continue to work for anyone if all certificates issued >>>>>> by major CAs that assert digSig and nonRep start having >>>>>> mandatory populated EKU values). >>>>>> >>>>>> I'll talk to Stefan tomorrow, but I'm leaning towards >>>>>> withdrawing our spot on the Agenda tomorrow, until we can >>>>>> come up with a Draft that addresses the concerns posted. >>>>>> (There's also the matter that Matt's not here, and I've got >>>>>> to leave before PKIX tomorrow :( ) >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Patrick. >>>>>> >>>>>> On 2012-07-31, at 5:02 PM, Sean Turner wrote: >>>>>> >>>>>>> I'm confused how a vague definition of a claim lines up >>>>>>> with the need for a specific EKU (from Patrick's earlier >>>>>>> message): >>>>>>> >>>>>>> Unfortunately, due to recent events regarding the abuse >>>>>>> of certificates asserting Key Usage values of >>>>>>> digitalSignature and nonRepudiation, a number of policy >>>>>>> authorities are mandating strict EKU values in all >>>>>>> certificates asserting these key usage values, and >>>>>>> mandating by policy that the anyEKU OID not be present. >>>>>>> >>>>>>> You need a specific EKU to indicate you can sign a >>>>>>> nebulous thing. What's the client going to check to know >>>>>>> whether it's signing a claim or not? >>>>>>> >>>>>>> spt >>>>>>> >>>>>>> On 7/31/12 10:55 AM, Stefan Santesson wrote: >>>>>>>> David, >>>>>>>> >>>>>>>> A broad definition of "Claim" may be appropriate, but >>>>>>>> there need to be one. Absent a definition, the EKU >>>>>>>> becomes somewhat pointless as usage declaration. >>>>>>>> >>>>>>>> /Stefan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 12-07-31 10:37 AM, "David A. Cooper" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Stefan, >>>>>>>>> >>>>>>>>> Based on earlier discussions that I've had with some >>>>>>>>> of the editors of this document, I believe that the >>>>>>>>> reason the draft isn't entirely clear about what >>>>>>>>> might constitute a "Claim" is that there is a desire >>>>>>>>> for the definition of this OID to be somewhat generic >>>>>>>>> so that in the future, when a key purpose OID is >>>>>>>>> needed to indicate that the subject is authorized to >>>>>>>>> sign "claims," this OID can be used rather than >>>>>>>>> having to define a new OID for each specific >>>>>>>>> application. >>>>>>>>> >>>>>>>>> As an example, there are some signed CMS objects on >>>>>>>>> PIV Cards. The CMS objects contain such things as >>>>>>>>> biometric data of the cardholder and/or a unique >>>>>>>>> identifier that has been assigned to the card. In >>>>>>>>> FIPS 201, a key purpose OID was defined, >>>>>>>>> id-PIV-content-signing, and there is a requirement >>>>>>>>> that the signer of the CMS objects on the PIV Card >>>>>>>>> must have a certificate that asserts the >>>>>>>>> id-PIV-content-signing key purpose OID. When >>>>>>>>> PIV-Interoperable cards were defined (similar to PIV >>>>>>>>> Cards, but not issued by the U.S. Federal >>>>>>>>> government), a new key purpose OID needed to be >>>>>>>>> defined for the signers of the CMS objects on those >>>>>>>>> cards, id-fpki-pivi-content-signing. It was noted >>>>>>>>> that if there were a generic "claim signing" OID, >>>>>>>>> then that OID could be used for both PIV and PIV-I >>>>>>>>> Cards in addition to other cards that don't qualify >>>>>>>>> as either PIV or PIV-I. We even received a comment on >>>>>>>>> the current draft of FIPS 201 >>>>>>>>> (http://csrc.nist.gov/publications/drafts/fips201-2/draft-fips-20 >>>>>>>>> >>>>>>>>> >> >>>>>>>>> 1-2_comme >>>>>>>>> >>>>>>>>> >>> nts_disposition-for-2011-draft.pdf) >>>>>>>>> asking that FIPS 201 specify the use of the >>>>>>>>> claimSigning OID being discussed in the PKIX WG >>>>>>>>> rather than (or in addition to) the >>>>>>>>> id-PIV-content-signing OID. >>>>>>>>> >>>>>>>>> Dave >>>>>>>>> >>>>>>>>> On 07/30/2012 03:04 PM, Stefan Santesson wrote: >>>>>>>>>> I have a number of issues/questions regarding this >>>>>>>>>> draft (still). >>>>>>>>>> >>>>>>>>>> 1) Definition of "Claim" This EKU is said to state >>>>>>>>>> that the subject is appropriate to sign "claims", >>>>>>>>>> but the draft does not make an effort to define >>>>>>>>>> what a claim is. It provides the examples SAML >>>>>>>>>> assertions and Attribute Assertions, but does not >>>>>>>>>> state what else could be regarded as a claim. Thus >>>>>>>>>> this EKU could be used for virtually anything in >>>>>>>>>> absence of a clear definition. >>>>>>>>>> >>>>>>>>>> 2) Explain when this EKU is needed, relative to >>>>>>>>>> metadata and pre-configured trust. The only >>>>>>>>>> examples are SAML. In SAML it is common to either >>>>>>>>>> preconfigure trust in assertion signers, removing >>>>>>>>>> the need for an EKU, or by placing the cert in >>>>>>>>>> signed metadata also removing the need for an EKU. >>>>>>>>>> What are the particular use-case where you would >>>>>>>>>> neither use metadata, nor pre-configured trust? A >>>>>>>>>> clarification of this would help the reader to >>>>>>>>>> understand when this EKU is appropriate. >>>>>>>>>> >>>>>>>>>> 3) Discussion about assurance levels and policy >>>>>>>>>> OIDs. When would you convey information about >>>>>>>>>> assurance level of an assertion in a certificate >>>>>>>>>> policy of the signing certificate? Information >>>>>>>>>> about assurance level is provided in SAML requests >>>>>>>>>> and responses. Information about what assurance >>>>>>>>>> level the IdP is trusted to provide (certified for) >>>>>>>>>> is normally provided in signed metadata (SAML) or >>>>>>>>>> may be implicit in the case of pre-configured >>>>>>>>>> trust. When would it be appropriate to solve this >>>>>>>>>> using cert policies? Is there any deployed examples >>>>>>>>>> of this? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /Stefan >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ pkix >>>>>>>> mailing list pkix@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>>>> >>>>>>> _______________________________________________ pkix >>>>>>> mailing list pkix@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>> >>>>>> --- Patrick Patterson President and Chief PKI Architect >>>>>> Carillon Information Security Inc. http://www.carillon.ca >>>>>> >>>>>> tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 >>>>>> 424 9559 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ pkix >>>>>> mailing list pkix@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>> >>>> >>>> --- Patrick Patterson President and Chief PKI Architect >>>> Carillon Information Security Inc. http://www.carillon.ca >>>> >>>> tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 >>>> 9559 >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ pkix mailing >>> list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>> > > --- Patrick Patterson President and Chief PKI Architect Carillon > Information Security Inc. http://www.carillon.ca > > tel: +1 514 485 0789 mobile: +1 514 994 8699 fax: +1 450 424 9559 > > > > > From simon@josefsson.org Wed Aug 1 16:14:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0AE11E82EF for ; Wed, 1 Aug 2012 16:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCoAYwFh8YHi for ; Wed, 1 Aug 2012 16:14:15 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFA411E81CC for ; Wed, 1 Aug 2012 16:14:14 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q71NDsWV018906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Aug 2012 01:13:56 +0200 From: Simon Josefsson To: Stephen Kent References: <50156F44.6010305@bbn.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120801:pkix@ietf.org::BvEF11y4e0UHKXOm:8poO X-Hashcash: 1:22:120801:kent@bbn.com::e8l8IXeXxAQ5vVYl:BLq0 Date: Thu, 02 Aug 2012 01:13:53 +0200 In-Reply-To: <50156F44.6010305@bbn.com> (Stephen Kent's message of "Sun, 29 Jul 2012 13:13:40 -0400") Message-ID: <87wr1ifbny.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: pkix Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:14:16 -0000 Stephen Kent writes: > So, let's begin a straw poll on the topic. Here are the options I am > offering: > > A - continue to work with the -05 version as the basis for an RFC > B - revert to the -04 version as the basis for an RFC > C - don't publish a clarifications document for OCSP > D - the respondent volunteers to work on a new version of 2560bis A /Simon From ppatterson@carillon.ca Wed Aug 1 16:14:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B255C11E831B for ; Wed, 1 Aug 2012 16:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccgUmd68WO3g for ; Wed, 1 Aug 2012 16:14:23 -0700 (PDT) Received: from mail.carillon.ca (mail.carillon.ca [207.115.107.18]) by ietfa.amsl.com (Postfix) with ESMTP id A352A11E830F for ; Wed, 1 Aug 2012 16:14:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id E7C2EA80572; Wed, 1 Aug 2012 19:14:32 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at rhea-new.carillon.ca Received: from mail.carillon.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6+yoyyN95uP; Wed, 1 Aug 2012 19:14:32 -0400 (EDT) Received: from [10.255.254.125] (s142-179-108-68.bc.hsia.telus.net [142.179.108.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTPSA id A469AA811BC; Wed, 1 Aug 2012 19:14:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Patrick Patterson In-Reply-To: <5019B055.60809@kent.ac.uk> Date: Wed, 1 Aug 2012 19:14:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <28F9444D-882B-46E8-98DA-2EEC1EC6FE60@carillon.ca> References: <501847DC.5030509@ieca.com> <50191269.8090000@kent.ac.uk> <5E5299BC-836C-4BD3-A0EA-904B5EF3D8E2@carillon.ca> <50195058.9090907@kent.ac.uk> <501992EB.5030501@kent.ac.uk> <0BEB4006-5762-42A5-BEC8-24F79A4184CF@carillon.ca> <5019B055.60809@kent.ac.uk> To: David Chadwick X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:14:24 -0000 Hello David, On 2012-08-01, at 6:40 PM, David Chadwick wrote: > Hi Patrick >=20 > On 01/08/2012 21:59, Patrick Patterson wrote: >> Hello David, >>=20 >> I think that your assumption only works in the case where the PMI >> operates their own CA (that signs only Metadata and/or IDP >> certificates). >=20 > Absolutely not. PMIs should always be designed to work with general = purpose PKIs and software (e.g. we use bouncy castle in our PMI). >=20 General Purpose PKIs !=3D PKI Products - I mean a PKI (regardless of = product, and meaning a collection of technology and processes that = enforce a policy regarding the binding of credentials to people and = things) that is used for every function in a given corporation / = community - including producing certificates for Identity of users (used = to log into web sites, VPNs, physical facilities, etc.), Signature = certificates to sign documents/data/etc., Encryption Certificates to = facilitate data security, Code Signing Certificates stating that a given = individual or organisation is allowed to sign trusted code, Device = Certificate used to provide identity assurance for web sites, etc. = Device Signature Certificates to prove origination of Data from an = automated Data source, etc., and now Device Certificates that say that a = given site is authorised to Sign "claims".=20 The products used to issue these Certificates should no have bearing on = this discussion, nor do the products used to consume or validate the = certificates. We don't make a distinction between Thunderbird (which = deals in Email) and LibNSS (which resolves certificate Trust) - why = should we distinguish between ADFS and CAPI (or whatever your Federation = product is and the underlying library that evaluates trust) - they are = (from a high level, user-oriented standpoint) indistinguishable - unless = they both work, the result is useless. As Trevor said - the stovepiping = of terminology that is currently happening is only causing confusion and = problems with comprehension in the folks that want to deploy this. >>=20 >> In a couple of cases that I am aware of, the same CA that issues >> Identity Certificates, general Purpose Device Certificates, there is >> a desire issue IDP Certs, and distinguish these from general purpose >> Device certificates. >=20 > "there is a desire" by whom? The CA operator? The federation operator? = The RP/SP? The PMI? >=20 The companies that have invested heavily in PKI. They are the CA = Operator, the RP and the Federation Operator, all at the same time. The = PMI is a community agreed Arbiter of Federation Trust, of which the = companies involved MAY be a part owner. >>=20 >> Furthermore, IDPs may be part of a dynamic Federation (it is >> sufficient to be part of the same PKI Community - we're treating >> Attribute Assurance separately), and therefore there IS no metadata. >=20 > Fine, I like that model much better. Metadata harks back to pre-DNS = days when sites used to be email the name-address mappings nightly. You = would have thought that federations would have learnt from that = experience that using metadata does not scale well. (The UK Access = Federation has belatedly found this out). >=20 Agreed. >=20 >> Consequently, the PMI and the PKI may be part of the same Trust >> Infrastructure, and therefore are not considered independent. >=20 > They are always independent. Just as authn is separate from authz, = trust in who issues claims is independent from who issues PKCs. Mixing = them together is a big mistake. (this does not mean that the same entity = cannot be trusted to do both, but logically they are separate roles) >=20 Well, no - there is no reason why a PMI and a PKI Bridge operator have = to be separate - they provide the same function - arbitrating Trust = between organisations - the only difference is a semantic one that a PMA = (A PKI is simply the entirety of stuff that carries out the will of a = PMA) deals in Identity Trust, and a PMI deals in Attribute Trust. Cheers, --- Patrick Patterson Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca From simon@josefsson.org Wed Aug 1 16:27:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9AD11E83DF for ; Wed, 1 Aug 2012 16:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3Dj2zvEriJv for ; Wed, 1 Aug 2012 16:27:07 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 31FB211E8334 for ; Wed, 1 Aug 2012 16:27:06 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q71NR4kw019568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 2 Aug 2012 01:27:06 +0200 X-Hashcash: 1:22:120801:pkix@ietf.org::dguSaYHLq1VEler+:1x9m From: Simon Josefsson To: pkix@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Thu, 02 Aug 2012 01:27:03 +0200 Message-ID: <87sjc6fb20.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: [pkix] OCSP 2560bis - responderID clarification X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:27:08 -0000 The semantics of the responderID field is something that may be useful to clarify in an RFC 2560 document. I brought this up earlier, but it may have been forgotten in the flurry of other issues: http://www.ietf.org/mail-archive/web/pkix/current/msg29802.html http://www.ietf.org/mail-archive/web/pkix/current/msg29803.html One good reason for not clarifying this would be if the intention is fussy or people are implementing different approaches. Does anyone know if that is the case? /Simon From mrex@sap.com Wed Aug 1 17:10:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C67521F899D for ; Wed, 1 Aug 2012 17:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.901 X-Spam-Level: X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkqkS85wyuZ1 for ; Wed, 1 Aug 2012 17:10:33 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0066D21F898F for ; Wed, 1 Aug 2012 17:10:32 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q720AVjI008132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Aug 2012 02:10:31 +0200 (MEST) To: pkix@ietf.org Date: Thu, 2 Aug 2012 02:10:31 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120802001031.3DC271A10B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Subject: [pkix] URN namespace for certs (pkix ietf84 presentation) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:10:34 -0000 A few comments on the presentation about the URN Namespace for Certificates from the IETF 84 PKIX WG session. There are existing standards for identifying certificates in textual form, and that is XMLdsig and standards derived from it (WS-Security from OASIS), >From the top of my head, the following references are defined: (a) Subject Name (of the certificate) (b) Issuer & Serial (c) SubjectKeyIdentifier (d) the cert itself (base64-encoded) I see a problem with the proposal of using a certificate hash in case there are situation when the certificate itself is _not_ conveyed along with the message. There are usage scenarios where instead of using a PKI, the consumer may decided to configure direct trust to the peer certificate. In order to do that, the consumer might have to import the certificate as "trust anchor", and potentially it is persisted in one of the formats defined for trust anchors in rfc5914 >From the three trust anchor formats defined in rfc5914, one is only the ToBeSigned part of a certificate, so a certificate hash is useless to find/identify that trust anchor, and for the trust anchor format "TrustAnchorInfo", storing the certificate is purely optional, so again, matching of a certificate hash may simply impossible. With respect to existing standards for referencing certificate in textual formats, look here: The WSS-X509TokenProfile-20040315.pdf document lists the following token references in Section 3.2: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf 3.2 Token References In order to ensure a consistent processing model across all the token types supported by WSS:SOAP Message Security, the element SHALL be used to specify all references to X.509 token types in signature or encryption elements that comply with this profile. A element MAY reference an X.509 token type by one of the following means: Reference to a Subject Key Identifier The element contains a element that specifies the token data by means of a X.509 SubjectKeyIdentifier reference. Reference to a Binary Security Token The element contains a element that references a local element or a remote data source that contains the token data itself. Reference to an Issuer and Serial Number The element contains a element that contains a element that uniquely identifies an end entity certificate by its X.509 Issuer and Serial Number. The basic XMLdsig spec is less specific here: http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo http://www.w3.org/TR/xmldsig-core/#dname-encrules 4.4.4.1 Distinguished Name Encoding Rules [...] Schema Definition -Martin From mrex@sap.com Wed Aug 1 17:26:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9495A11E810C for ; Wed, 1 Aug 2012 17:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.193 X-Spam-Level: X-Spam-Status: No, score=-10.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyCG1euiRuNZ for ; Wed, 1 Aug 2012 17:26:47 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 52EB111E80FD for ; Wed, 1 Aug 2012 17:26:47 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q720QfIl009761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 02:26:46 +0200 (MEST) In-Reply-To: <5007142A.5060302@seantek.com> To: Sean Leonard Date: Thu, 2 Aug 2012 02:26:41 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120802002641.1C64D1A10B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Text Encodings of PKIX and CMS Structures (-01) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:26:48 -0000 Comments based on the PKIX @ IETF-84 presentation. I typically refer to the textual format as "PEM-framed, base64-encoded Format", because of the PEM boundary markers. The code I have written myself will choke on any Mime-Headers inserted after the -----BEGIN boundary marker -- except for the support of the OpenSSL PKCS5 encrypted private key, where these headers are AFAIK necessary for processing/decoding the content. A while ago I did add support for conveying CRLs out-of-band (file-based), but realized that for really making an offline CRL check feasible, it would be reasonable to convey a "bag-of-CRLs" packaged in a single file, rather than individual CRLs, and chose PKCS#7 SIGNED_DATA with no data as the container. Individual, plain CRLs are also supported an treated as a bag-of-CRL containing exactly one CRL. -Martin Sean Leonard wrote: > Greetings PKIX: > > Simon Josefsson and I have been working on the -01 revision to > "pkix-textual", currently titled: > Text Encodings of PKIX and CMS Structures > > We would like to propose this for adoption as a WG item. > > In comparison to the original -00 draft, this revision has several > changes, including: > - more history > - discussion of interoperability > - inclusion of CMS and PKCS #8/Asymmetric Key types > - ABNF > - addresses certain points made off-list > > Some may have some questions, like "why 'X509 CRL' and not 'CRL'" and so > forth. Hopefully the draft addresses those, but I am also working on a > compatibility matrix that records what a lot of common implementations > actually emit or accept (the tests have been done, but need to be put > into a digestible spreadsheet). Most statements in the draft are based > on interoperability tests and experience, for maximum compatibility. From mrex@sap.com Wed Aug 1 22:09:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A2321F8B1F for ; Wed, 1 Aug 2012 22:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.195 X-Spam-Level: X-Spam-Status: No, score=-10.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tnf+u-aenXnW for ; Wed, 1 Aug 2012 22:09:38 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9921F84F8 for ; Wed, 1 Aug 2012 22:09:34 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q7259Mgw005771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 07:09:22 +0200 (MEST) In-Reply-To: To: Stefan Santesson Date: Thu, 2 Aug 2012 07:09:21 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120802050921.E3BDF1A10A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Patrick Patterson , pkix@ietf.org Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 05:09:40 -0000 Stefan Santesson wrote: > > > > Unfortunately, due to recent events regarding the > >abuse of certificates asserting Key Usage values of digitalSignature and > >nonRepudiation, a number of policy authorities are mandating strict EKU > >values in all certificates asserting these key usage values, and > >mandating by policy that the anyEKU OID not be present. This means, that > >absent this EKU value, we can't have claims signed by IDPs using PKI > >Certificate credentials, due to strict RFC5280 enforcement. > > I'm sorry, I still don't get this. If you find the cert in the metadata, > you know that it is suitable to sign assertions. All verifier of the > assertion consume metadata. > Major implementations of SAML can handle this. They don't need any EKU. > > I'm just asking you to clarify the use case and to position it relative to > SAML metadata usage, which obviously works today. The request seems to be motivated by a bureaucratic cover-your-ass policy approach of some CAs or "policy authorities", rather than from a genuine need to change the security properties of SAML. It is close to impossible to change the security properties of a long deployed installed base of a technology such as SAML just by throwing an EKU definition after them. The necessary sequence of events is probably: 1. an EKU needs to be selected or assigned (since this is a plain ASN.1 OID, *ANY* OID will do, asking PKIX for an OID is just adding pain...) 2. add the EKU and the desired semantics to a revision or new version of the SAML spec (or whatever). 3. wait for implementations to adopt the new features 4. wait for updated implementations to get deployed 5. decide when to start "enforcing" that EKUs are present on the certs that signed claims. -Martin From mrex@sap.com Wed Aug 1 23:30:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F10B11E80E1 for ; Wed, 1 Aug 2012 23:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6TEeYkFfgeW for ; Wed, 1 Aug 2012 23:30:17 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4347411E8128 for ; Wed, 1 Aug 2012 23:30:16 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q726U55O013140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 08:30:10 +0200 (MEST) In-Reply-To: <50193573.1090303@nist.gov> To: "David A. Cooper" Date: Thu, 2 Aug 2012 08:30:05 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120802063005.0455D1A10A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] 2560bis (essay version) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 06:30:18 -0000 David A. Cooper wrote: > > I was given a very strict mandate to not make any changes to OCSP. Can > you show me where this "MUST" requirement appears in RFC 2560? If not, > then how could I include such a "MUST" requirement in 2560bis without > breaking my promise not to make any changes to the protocol. This > proposed change may be a good idea, but that doesn't mean it's not a change. What could be done in order to minimize the changes to the original protocol is adding one or more appendixes that specify "interop profiles", showing which additional requirements will result in what kind of interop improvements. Any new/additional requirement may imply a patch/change/update of at least parts of the installed base, of course. The focus should be, what minimum set of additional/new requirements will provide reliable interop on which exact protocol option. And new requirements(=changes) for the OCSP responder or the PKI/CA will often be easier to deploy than changes to the unwashed masses of OCSP clients (RPs). That does not necessarily mean that it will be easier to get a software for the OCSP server or CA than for the OCSP client from the respecitive software suppliers... > > You also say that "There really ought to be a requirement that > implementations (of CA and OCSP software) MUST support short-lived OCSP > signer certs...." Again, that may be a good idea, but can you find that > requirement in RFC 2560? If not, then wouldn't including such a > requirement in 2560bis be a change? That is sort-of a prerequisite for making OCSP processing work reliably. Think of the new TLS extension for stapling OCSP responses. The objective is that a client can connect to a server, obtain the server certificate along with **ALL** OCSP responses necessary to verify the server certificate from the TLS handshake and not having to do _any_ third party communication at all. The algorithm for the server to obtain the necessary OCSP responses allowing this should be simple and straight-forward. If verification of OCSP signer certs would need additional OCSP responsed or CRLs, then it would no longer be simple and straightforward. -Martin From d.w.chadwick@kent.ac.uk Thu Aug 2 00:32:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758EE21F8CFD for ; Thu, 2 Aug 2012 00:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lzl0dgS4AAyy for ; Thu, 2 Aug 2012 00:32:54 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1CD21E8034 for ; Thu, 2 Aug 2012 00:32:53 -0700 (PDT) Received: from mx4.kent.ac.uk ([129.12.21.35]) by mx1.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Swptp-0001Z4-U0; Thu, 02 Aug 2012 08:32:49 +0100 Received: from [31.185.215.137] (helo=[192.168.1.38]) by mx4.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Swptp-00047Q-0J; Thu, 02 Aug 2012 08:32:49 +0100 Message-ID: <501A2D22.4040103@kent.ac.uk> Date: Thu, 02 Aug 2012 08:32:50 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mrex@sap.com References: <20120802050921.E3BDF1A10A@ld9781.wdf.sap.corp> In-Reply-To: <20120802050921.E3BDF1A10A@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Patrick Patterson , Stefan Santesson , pkix@ietf.org Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 07:32:56 -0000 The series of events is even simpler than you suggest, see below On 02/08/2012 06:09, Martin Rex wrote: > Stefan Santesson wrote: >>> >>> Unfortunately, due to recent events regarding the >>> abuse of certificates asserting Key Usage values of digitalSignature and >>> nonRepudiation, a number of policy authorities are mandating strict EKU >>> values in all certificates asserting these key usage values, and >>> mandating by policy that the anyEKU OID not be present. This means, that >>> absent this EKU value, we can't have claims signed by IDPs using PKI >>> Certificate credentials, due to strict RFC5280 enforcement. >> >> I'm sorry, I still don't get this. If you find the cert in the metadata, >> you know that it is suitable to sign assertions. All verifier of the >> assertion consume metadata. >> Major implementations of SAML can handle this. They don't need any EKU. >> >> I'm just asking you to clarify the use case and to position it relative to >> SAML metadata usage, which obviously works today. > > The request seems to be motivated by a bureaucratic cover-your-ass > policy approach of some CAs or "policy authorities", rather than from > a genuine need to change the security properties of SAML. > > It is close to impossible to change the security properties of > a long deployed installed base of a technology such as SAML > just by throwing an EKU definition after them. > > The necessary sequence of events is probably: > > 1. an EKU needs to be selected or assigned > (since this is a plain ASN.1 OID, *ANY* OID will do, > asking PKIX for an OID is just adding pain...) use the existing standard SOAidentifier extension and the OID defined for this. Note that this extension is NOT critical, which is what you need in order for the migration to succeed successfully. Using a critical extension will screw up any chance of migration or interworking. > > 2. add the EKU and the desired semantics to a revision or > new version of the SAML spec (or whatever). add this to profile of SAML > > 3. wait for implementations to adopt the new features > > 4. wait for updated implementations to get deployed > > 5. decide when to start "enforcing" that EKUs are present on > the certs that signed claims. You dont need to enforce it ever, since the rules for non-critical extension processing mean that once an implementation understands the extension is must follow it. So enforcement becomes automatic once the certificate processing code is updated. regards David > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From mrex@sap.com Thu Aug 2 00:49:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BC821F8C84 for ; Thu, 2 Aug 2012 00:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqrDXxXv+s3j for ; Thu, 2 Aug 2012 00:49:53 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D47ED21F8C5B for ; Thu, 2 Aug 2012 00:49:52 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q727nlhb021355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 09:49:47 +0200 (MEST) In-Reply-To: <501A2D22.4040103@kent.ac.uk> To: David Chadwick Date: Thu, 2 Aug 2012 09:49:46 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120802074946.9090A1A10A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Patrick Patterson , Stefan Santesson , pkix@ietf.org Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 07:49:53 -0000 David Chadwick wrote: > The series of events is even simpler than you suggest, see below > > On 02/08/2012 06:09, Martin Rex wrote: > > > > The necessary sequence of events is probably: > > > > 1. an EKU needs to be selected or assigned > > (since this is a plain ASN.1 OID, *ANY* OID will do, > > asking PKIX for an OID is just adding pain...) > > use the existing standard SOAidentifier extension and the OID defined > for this. Note that this extension is NOT critical, which is what you > need in order for the migration to succeed successfully. Using a > critical extension will screw up any chance of migration or interworking. This might be somewhat optimistic (IMHO unrealistic) about the meaning of criticality of a certificate extension that by itself is fairly meaningless to the PKIX certificate path validation function. An application that doesn't care about EKU will often ... simply not care about EKU. > > > > > 2. add the EKU and the desired semantics to a revision or > > new version of the SAML spec (or whatever). > > add this to profile of SAML This addition would also have to specify whether "anyKeyPurpose" is OK. > > > > > 3. wait for implementations to adopt the new features > > > > 4. wait for updated implementations to get deployed > > > > 5. decide when to start "enforcing" that EKUs are present on > > the certs that signed claims. > > You dont need to enforce it ever, since the rules for non-critical > extension processing mean that once an implementation understands the > extension is must follow it. So enforcement becomes automatic once the > certificate processing code is updated. "Enforcing" means that the "app" (SAML) would have to check whether the certificate contained an EKU cert extension, and when it did, check whether the EKU extension contained the specific KeyPurpose(O)ID in question, and abort with an error if EKU was present, but the specific SAML KeyPurpose(O)ID was missing (or anyKeyPurpose is present and acceptable). -Martin From d.w.chadwick@kent.ac.uk Thu Aug 2 00:51:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1015C21F8C9A for ; Thu, 2 Aug 2012 00:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.266 X-Spam-Level: X-Spam-Status: No, score=-7.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6kVd4YRO3rm for ; Thu, 2 Aug 2012 00:50:59 -0700 (PDT) Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9890C21F8C99 for ; Thu, 2 Aug 2012 00:50:59 -0700 (PDT) Received: from mx4.kent.ac.uk ([129.12.21.35]) by mx1.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwqBO-0002Vv-PD; Thu, 02 Aug 2012 08:50:58 +0100 Received: from [31.185.215.137] (helo=[192.168.1.38]) by mx4.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwqBO-0005RF-8U; Thu, 02 Aug 2012 08:50:58 +0100 Message-ID: <501A3163.7080307@kent.ac.uk> Date: Thu, 02 Aug 2012 08:50:59 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Patrick Patterson References: <501847DC.5030509@ieca.com> <50191269.8090000@kent.ac.uk> <5E5299BC-836C-4BD3-A0EA-904B5EF3D8E2@carillon.ca> <50195058.9090907@kent.ac.uk> <501992EB.5030501@kent.ac.uk> <0BEB4006-5762-42A5-BEC8-24F79A4184CF@carillon.ca> <5019B055.60809@kent.ac.uk> <28F9444D-882B-46E8-98DA-2EEC1EC6FE60@carillon.ca> In-Reply-To: <28F9444D-882B-46E8-98DA-2EEC1EC6FE60@carillon.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org PKIX" Subject: Re: [pkix] Updated claimSigning EKU Internet Draft X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 07:51:01 -0000 Hi Patrick It seems that we do not share a common viewpoint. I say that PKI and PMI are separate functions and that an AA and CA are separate roles, but the same entity can act in both roles. However you said they provide the same function. I should like you to justify this, and perhaps you can use as an example a university AA which issues degree attributes and a CA which issues PKCs. regards David On 02/08/2012 00:14, Patrick Patterson wrote: > Hello David, > > On 2012-08-01, at 6:40 PM, David Chadwick wrote: > >> Hi Patrick >> >> On 01/08/2012 21:59, Patrick Patterson wrote: >>> Hello David, >>> >>> I think that your assumption only works in the case where the >>> PMI operates their own CA (that signs only Metadata and/or IDP >>> certificates). >> >> Absolutely not. PMIs should always be designed to work with general >> purpose PKIs and software (e.g. we use bouncy castle in our PMI). >> > > General Purpose PKIs != PKI Products - I mean a PKI (regardless of > product, and meaning a collection of technology and processes that > enforce a policy regarding the binding of credentials to people and > things) that is used for every function in a given corporation / > community - including producing certificates for Identity of users > (used to log into web sites, VPNs, physical facilities, etc.), > Signature certificates to sign documents/data/etc., Encryption > Certificates to facilitate data security, Code Signing Certificates > stating that a given individual or organisation is allowed to sign > trusted code, Device Certificate used to provide identity assurance > for web sites, etc. Device Signature Certificates to prove > origination of Data from an automated Data source, etc., and now > Device Certificates that say that a given site is authorised to Sign > "claims". > > The products used to issue these Certificates should no have bearing > on this discussion, nor do the products used to consume or validate > the certificates. We don't make a distinction between Thunderbird > (which deals in Email) and LibNSS (which resolves certificate Trust) > - why should we distinguish between ADFS and CAPI (or whatever your > Federation product is and the underlying library that evaluates > trust) - they are (from a high level, user-oriented standpoint) > indistinguishable - unless they both work, the result is useless. As > Trevor said - the stovepiping of terminology that is currently > happening is only causing confusion and problems with comprehension > in the folks that want to deploy this. > > >>> >>> In a couple of cases that I am aware of, the same CA that issues >>> Identity Certificates, general Purpose Device Certificates, there >>> is a desire issue IDP Certs, and distinguish these from general >>> purpose Device certificates. >> >> "there is a desire" by whom? The CA operator? The federation >> operator? The RP/SP? The PMI? >> > > The companies that have invested heavily in PKI. They are the CA > Operator, the RP and the Federation Operator, all at the same time. > The PMI is a community agreed Arbiter of Federation Trust, of which > the companies involved MAY be a part owner. > >>> >>> Furthermore, IDPs may be part of a dynamic Federation (it is >>> sufficient to be part of the same PKI Community - we're treating >>> Attribute Assurance separately), and therefore there IS no >>> metadata. >> >> Fine, I like that model much better. Metadata harks back to pre-DNS >> days when sites used to be email the name-address mappings nightly. >> You would have thought that federations would have learnt from that >> experience that using metadata does not scale well. (The UK Access >> Federation has belatedly found this out). >> > > Agreed. > >> >>> Consequently, the PMI and the PKI may be part of the same Trust >>> Infrastructure, and therefore are not considered independent. >> >> They are always independent. Just as authn is separate from authz, >> trust in who issues claims is independent from who issues PKCs. >> Mixing them together is a big mistake. (this does not mean that the >> same entity cannot be trusted to do both, but logically they are >> separate roles) >> > > Well, no - there is no reason why a PMI and a PKI Bridge operator > have to be separate - they provide the same function - arbitrating > Trust between organisations - the only difference is a semantic one > that a PMA (A PKI is simply the entirety of stuff that carries out > the will of a PMA) deals in Identity Trust, and a PMI deals in > Attribute Trust. > > Cheers, > > --- Patrick Patterson Chief PKI Architect Carillon Information > Security Inc. http://www.carillon.ca > > > > > From david.cooper@nist.gov Thu Aug 2 07:45:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348A511E80D3 for ; Thu, 2 Aug 2012 07:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eiaz2AUEUyRR for ; Thu, 2 Aug 2012 07:45:40 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 6E85711E80A3 for ; Thu, 2 Aug 2012 07:45:39 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Aug 2012 10:45:10 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Thu, 2 Aug 2012 10:44:15 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q72EjE6Y004080; Thu, 2 Aug 2012 10:45:16 -0400 Message-ID: <501A927A.7050308@nist.gov> Date: Thu, 2 Aug 2012 10:45:14 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120723 Thunderbird/14.0 MIME-Version: 1.0 To: "mrex@sap.com" References: <20120801202242.50D1E1A10B@ld9781.wdf.sap.corp> In-Reply-To: <20120801202242.50D1E1A10B@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix Subject: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5280bis, Section 3.2) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:45:41 -0000 Martin, I don't know why you find the example "thoroughly confusing" or "a bad idea in general," but if you think this is such a bad example, what would you propose as a good example of a locally trusted OCSP responder? Dave On 08/01/2012 04:22 PM, Martin Rex wrote: > From the parallel discussion thread about OCSP 2560bis, I noticed > a throroughly confusing example in Appendix E.3 > Locally Trusted OCSP Responder at the end of -04 document: > > http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-04#page-42 > > which uses a self-signed certificate of a non-CA entity. > > This is outside of PKIX/rfc5280 and an option not listed under 2.3.5.2: > > http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-04#section-2.3.5.2 > > and looks to _me_ like a bad idea in general. > > > -Martin From david.cooper@nist.gov Thu Aug 2 08:30:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0FA21F866B for ; Thu, 2 Aug 2012 08:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqI6samypP-i for ; Thu, 2 Aug 2012 08:30:54 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1C021F8669 for ; Thu, 2 Aug 2012 08:30:54 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Aug 2012 11:30:46 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Thu, 2 Aug 2012 11:29:52 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q72FUpnc011125; Thu, 2 Aug 2012 11:30:52 -0400 Message-ID: <501A9D2C.6000704@nist.gov> Date: Thu, 2 Aug 2012 11:30:52 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120723 Thunderbird/14.0 MIME-Version: 1.0 To: "mrex@sap.com" References: <20120801212009.D99891A10B@ld9781.wdf.sap.corp> In-Reply-To: <20120801212009.D99891A10B@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix Subject: Re: [pkix] 2560bis (essay version) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:30:55 -0000 Martin, As you voted for option A in the straw poll, please provide Stefan with this formal correctness proof so that he can address any aspects of the protocol that are underspecified, in case future development of 2560bis is based on option A. Dave On 08/01/2012 05:20 PM, Martin Rex wrote: > If you approach rfc2560 from the viewpoint of formal correctness proofing, > you will immediately notice which protocol options are underspecified > and where you will encounter interop problems with implementers who > do not read a spec and create an implementation with any kind of formal > correctness in mind (i.e. planned and predictable behaviour > in unknown future usage scenarios). From kent@bbn.com Thu Aug 2 09:43:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F97C21E8042 for ; Thu, 2 Aug 2012 09:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWHZxvUiX29C for ; Thu, 2 Aug 2012 09:43:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C27DE21E8040 for ; Thu, 2 Aug 2012 09:43:20 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50833 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SwyUa-00078O-Ak for pkix@ietf.org; Thu, 02 Aug 2012 12:43:20 -0400 Message-ID: <501AAE27.4030305@bbn.com> Date: Thu, 02 Aug 2012 12:43:19 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: pkix Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] minutes posted X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:43:21 -0000 Please contact me with comments and corrections, over the next 10-12 days. Thanks, Steve From Scott@DigiCert.com Thu Aug 2 09:47:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD1A21E8088 for ; Thu, 2 Aug 2012 09:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcWoiyh0aXse for ; Thu, 2 Aug 2012 09:47:43 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABA021E8082 for ; Thu, 2 Aug 2012 09:47:43 -0700 (PDT) Received: from [10.211.55.9] (dhcp-11b6.meeting.ietf.org [130.129.17.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id E7073906CA8 for ; Thu, 2 Aug 2012 10:47:42 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1343926063; bh=ooUHrXF0yK3/Bt0CsugZB9HKg+DzG+z6xI8b22d40es=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=k0wAMmBwkPQRbMSq3PybeB+/f6vl0K+pfYcYKUGt+YqSD74trDhrZx0dz+gzTB1CY iSEhSJ43NDvyify3y+XDPfwiz4ZhAB9CiGbHRA9EQpIf5YhT4tJSXpp6pSA7lVHIMr pS6Z4nG1UDFKdw87fgXYtvlo0afTiuArRwt4eFxQ= Message-ID: <501AAF29.9030307@DigiCert.com> Date: Thu, 02 Aug 2012 10:47:37 -0600 From: Scott Rea User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:47:44 -0000 G'day Folks, yesterday at PKIX we had some folks supporting the proposed OCSP over DNS protocol (see: https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/) and some folks who said they did not like the idea. Time was short and I failed to get further feedback from the folks who "hated" (yes that was the exact phrase that was used) the idea as to WHY they do not support the idea. Would those folks be willing to post their objections/justifications to the list, and if are not quite ready to make a public declaration, please send Max or I an email directly off-list as to reasons why you would not support this proposal? Scott Rea or Massimiliano Pala Regards, -- Scott Rea From kent@bbn.com Thu Aug 2 10:06:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E1021E80C1 for ; Thu, 2 Aug 2012 10:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjGyeGt4Zkjm for ; Thu, 2 Aug 2012 10:06:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7A14521E80C0 for ; Thu, 2 Aug 2012 10:06:44 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39785 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SwyrE-0003oU-8l for pkix@ietf.org; Thu, 02 Aug 2012 13:06:44 -0400 Message-ID: <501AB3A3.4020209@bbn.com> Date: Thu, 02 Aug 2012 13:06:43 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: pkix Content-Type: multipart/alternative; boundary="------------070809040604050608090107" Subject: [pkix] reminder X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:06:46 -0000 This is a multi-part message in MIME format. --------------070809040604050608090107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Below is the text that was briefed in the PKIX meeting yesterday and that represents the current, proposed text for addition to Section 3.2. Russ noted that we need to add a reference to the 2008 version of X.509 from which we have cited text. Peter will reissue the doc with this change. I plan to forward that version to the IESG a week after it is posted, unless we hear otherwise. Steve ----- Add the following paragraph to the end of RFC 5280, Section 3.2: Consistent with Section 3.4.61 of X.509 (11/2008) we note that use of self-issued certificates and self-signed certificates issued by other than CAs are outside the scope of this specification. Thus, for example, a web server or client might generate a self-signed certificate to identify itself. These certificates, and how a relying party uses them to authenticate asserted identities, are both outside the scope of RFC 5280. --------------070809040604050608090107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Below is the text that was briefed in the PKIX meeting yesterday and that represents
the current, proposed text for addition to Section 3.2. Russ noted that we need to
add a reference to the 2008 version of X.509 from which we have cited text.  Peter will
reissue the doc with this change. I plan to forward that version to the IESG a week after
it is posted, unless we hear otherwise.

Steve
-----

Add the following paragraph to the end of RFC 5280, Section 3.2:

Consistent with Section 3.4.61 of X.509 (11/2008) we note that use of self-issued certificates and self-signed certificates issued by other than CAs are outside the scope of this specification. Thus, for example, a web server or client might generate a self-signed certificate to identify itself. These certificates, and how a relying party uses them to authenticate asserted identities, are both outside the scope of RFC 5280.


--------------070809040604050608090107-- From stefan@aaa-sec.com Thu Aug 2 10:09:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EBA21E80F8 for ; Thu, 2 Aug 2012 10:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.992 X-Spam-Level: X-Spam-Status: No, score=-102.992 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL78B9N6aANY for ; Thu, 2 Aug 2012 10:09:37 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id C27EA21E80F5 for ; Thu, 2 Aug 2012 10:09:36 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id EBA471FAB2DB for ; Thu, 2 Aug 2012 19:09:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WmX-u-lkTq4w for ; Thu, 2 Aug 2012 19:09:25 +0200 (CEST) Received: from s328.loopia.se (new-s34.loopia.se [194.9.94.94]) by s87.loopia.se (Postfix) with ESMTP id 6EEDB1FAB2D9 for ; Thu, 2 Aug 2012 19:09:25 +0200 (CEST) Received: (qmail 91297 invoked from network); 2 Aug 2012 17:09:24 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.204]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 2 Aug 2012 17:09:24 -0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Thu, 02 Aug 2012 10:09:19 -0700 From: Stefan Santesson To: "Polk, William T." , Stephen Kent , pkix Message-ID: Thread-Topic: [pkix] 2560bis (essay version) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] 2560bis (essay version) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:09:38 -0000 Tim, You say that "Our experience with implementations of RFC 2560 has been decidedly mixed" I have in the past years developed tools for signature validation within the EU trust framework. This involves 800+ trust services, many of them providing OCSP. My experience with interoperating with a vast amount of OCSP responders in EU is that the practically only technical issue I ever have encountered, is related to certificate chaining to the OCSP responder. Except from that I have encountered some OCSP responders (very few though) that don't think I'm authorized to ask for some reason, but that is not a technical interop failure. So in my experience, RFC 2560 does in large work very well in creating interoperability, except for the chaining issue. If your experience is different from mine, it would be really helpful to get a list of recorded interop issues. Even a rough list would be helpful. It would certainly help knowing what needs fixing and to determine if a complete re-write is motivated. /Stefan On 12-07-31 5:21 PM, "Polk, William T." wrote: >My apologies for the essay, but since I can't be at the session tomorrow >I wanted to add >a rationale. Since Steve asked that we *not* supply an essay, I am >supplying my rant in a >separate message. > >First, I want to note that I support the chairs effort to bring 2560bis >to publication ASAP. >There is a real need. Experience shows that implementers who weren't in >the room/on the list >in 1999 have interpreted some text inconsistently, and have encountered >problems (e.g. >key rollover) that were not treated as comprehensively as we believed at >the time. > >I would gladly support Option A if I thought it would produce a document >that >could produce interoperable implementations in a timely manner, but I >just don't see it. Our >experience with implementations of RFC 2560 has been decidedly mixed, and >those >implementations weren't particularly agile. I don't think a minor edit >of 2560 will meet the >need, so restarting will from 2560 will either produce a document that >falls short or will take >a lot more effort than Stefan believes. > >No document is ever perfect, but I think that the -04 needs very little >work to be publishable. >I believe that most of the new text in the document is needed to answer >errors of omission >in 2560 (which is why I think restarting from 2560 will be less efficient >than you expect.) >As I recall, Santosh has some issues that he thinks could be addressed >efficiently (and has >offered to help). Denis has asked for a lot more work, but I think he is >in the rough (and option >A won't change that.) Based on that analysis, I suggest option B as most >efficent. > >The most important thing, though, is not whether we choose A or B. It is >getting a document >published that fills in the gaps in RFC 2560 in a reasonable timeframe. >One path forward might >be to double-check the email list and compile the set of problems to be >addressed. I would >start with David's slides for presentation at the meetings since he >usually listed the >issues he was addressing. Modify the list if it is too long or >incomplete, then compare. If the list >has all been addressed in -04 we are done. If not, consider which will >take more work. > >My 2 cents. > >Tim Polk > >________________________________________ >From: Polk, William T. >Sent: Tuesday, July 31, 2012 7:46 PM >To: Stephen Kent; pkix >Subject: RE: [pkix] 2560bis > >B. > >________________________________________ >From: pkix-bounces@ietf.org [pkix-bounces@ietf.org] On Behalf Of Stephen >Kent [kent@bbn.com] >Sent: Sunday, July 29, 2012 1:13 PM >To: pkix >Subject: [pkix] 2560bis > >Folks, > >Recent messages exchanges point to significant disagreement about the >future direction >for this doc. At the March meeting Stefan presented a proposal for how >to move >ahead, as outlined in his slides. As noted in the minutes, the audience >(at the mic) >included one indication of support for this streamlined approach, and >one expression >of concern. Not a lot of interest. > >Work on this doc has dragged on for 2 years now. In October of 2011 >Santosh argued that >version -04 of the doc was, in his opinion, a step backwards, adding >more confusion to >RFC 2560 vs. clarifying it. Stefan agreed (in a message in March of >2012), and >thus he created the current, stripped-down version of the doc (-05) >which was published >recently. > >Given the mixed response to this version, it's not clear that the WG >members who are interested >in OCSP clarifications are in agreement on how to proceed. > >So, let's begin a straw poll on the topic. Here are the options I am >offering: > > A - continue to work with the -05 version as the basis for an RFC > B - revert to the -04 version as the basis for an RFC > C - don't publish a clarifications document for OCSP > D - the respondent volunteers to work on a new version of 2560bis > >Please send your replies to the list starting now. The straw poll will >close >in two weeks, on August 12. While there are many other, legitimate >comments one could >offer, I am interested only in replies to this multiple choice straw >poll (i.e., no >essay replies :-) ) > >Thanks, > >Steve > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From Francis.Dupont@fdupont.fr Thu Aug 2 10:32:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C2221E8106 for ; Thu, 2 Aug 2012 10:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiTM4GnI3SwQ for ; Thu, 2 Aug 2012 10:32:09 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 9770621E8103 for ; Thu, 2 Aug 2012 10:32:08 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q72HW5Jr070976; Thu, 2 Aug 2012 19:32:05 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201208021732.q72HW5Jr070976@givry.fdupont.fr> From: Francis Dupont To: Scott Rea In-reply-to: Your message of Thu, 02 Aug 2012 10:47:37 MDT. <501AAF29.9030307@DigiCert.com> Date: Thu, 02 Aug 2012 19:32:05 +0200 Sender: Francis.Dupont@fdupont.fr Cc: pkix@ietf.org Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:32:09 -0000 In your previous mail you wrote: > Time was short and I failed to get further feedback from the folks > who "hated" (yes that was the exact phrase that was used) the idea > as to WHY they do not support the idea. => I attended another session so I didn't follow the presentation itself but according to the slides in the meeting materials I am afraid I deeply dislike the idea (i.e., haters++). BTW the DNS is in no way a "transport". Regards Francis.Dupont@fdupont.fr (and for this time I am making an exception, fdupont@isc.org too) From Scott@DigiCert.com Thu Aug 2 10:41:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A480111E81A5 for ; Thu, 2 Aug 2012 10:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fs8q4gTPOWXZ for ; Thu, 2 Aug 2012 10:41:24 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id E814C11E81A2 for ; Thu, 2 Aug 2012 10:41:20 -0700 (PDT) Received: from [10.211.55.9] (dhcp-11b6.meeting.ietf.org [130.129.17.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 5222A906CA8; Thu, 2 Aug 2012 11:41:19 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1343929279; bh=ZAAX4/MlWXUk4bwnaJ1hqJ4gE/1kwbuzBt7Zhw1nQGw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=EKPNlObBFVyDP8Wp9I8f5HsKU6/9My6TLRr8is2KZ/jVj/Ij0kLP/dMWUsow12vaq yZz87PMD2oDrmPGpmvXa+PKRFniTJQYiLHXH/HnDelxsZDdIeDa8EaTMy1uj3HXVBd k888C98FYfYjyVTRst1mUu3CIJz6FZUHLO9iNlBs= Message-ID: <501ABBBA.1020905@DigiCert.com> Date: Thu, 02 Aug 2012 11:41:14 -0600 From: Scott Rea User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: Francis Dupont References: <201208021732.q72HW5Jr070976@givry.fdupont.fr> In-Reply-To: <201208021732.q72HW5Jr070976@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:41:26 -0000 Thanks Francis! could you elaborate on WHY you do not like this proposal? We do not have any concrete data on what is at the source of haters' objections. There was a comment in the meeting about further burdening DNS, which we accept as a concrete reason for objection, but other than that, we seem to just have ephemeral statements of preferences rather than concrete reasoning behind the preferences - are you willing to lay out you base reasons for rejection? Regards, _Scott On 8/2/2012 11:32 AM, Francis Dupont wrote: > In your previous mail you wrote: > >> Time was short and I failed to get further feedback from the folks >> who "hated" (yes that was the exact phrase that was used) the idea >> as to WHY they do not support the idea. > => I attended another session so I didn't follow the presentation itself > but according to the slides in the meeting materials I am afraid I deeply > dislike the idea (i.e., haters++). BTW the DNS is in no way a "transport". > > Regards > > Francis.Dupont@fdupont.fr > (and for this time I am making an exception, fdupont@isc.org too) From peter.sylvester@edelweb.fr Thu Aug 2 10:46:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4C711E81B3 for ; Thu, 2 Aug 2012 10:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWmWwfQCM++S for ; Thu, 2 Aug 2012 10:46:04 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3061811E80D3 for ; Thu, 2 Aug 2012 10:46:04 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 73BCA5E0F8 for ; Thu, 2 Aug 2012 19:43:59 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 557327CC12 for ; Thu, 2 Aug 2012 19:19:45 +0200 (CEST) Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id 2ECC4236338 for ; Thu, 2 Aug 2012 13:23:52 -0400 (EDT) Message-ID: <501ABCFB.7040907@edelweb.fr> Date: Thu, 02 Aug 2012 19:46:35 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: pkix@ietf.org References: <501AB3A3.4020209@bbn.com> In-Reply-To: <501AB3A3.4020209@bbn.com> Content-Type: multipart/alternative; boundary="------------090306000503030305050401" Subject: Re: [pkix] reminder X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:46:05 -0000 This is a multi-part message in MIME format. --------------090306000503030305050401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/02/2012 07:06 PM, Stephen Kent wrote: > Below is the text that was briefed in the PKIX meeting yesterday and > that represents > the current, proposed text for addition to Section 3.2. Russ noted > that we need to > add a reference to the 2008 version of X.509 from which we have cited > text. Peter will > reissue the doc with this change. I plan to forward that version to > the IESG a week after > it is posted, unless we hear otherwise. Could one change 'generate' to 'want to use' ? TIA > > Steve > ----- > > Add the following paragraph to the end of RFC 5280, Section 3.2: > > Consistent with Section 3.4.61 of X.509 (11/2008) we note that use of > self-issued certificates and self-signed certificates issued by other > than CAs are outside the scope of this specification. Thus, for > example, a web server or client might generate a self-signed > certificate to identify itself. These certificates, and how a relying > party uses them to authenticate asserted identities, are both outside > the scope of RFC 5280. > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------090306000503030305050401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 08/02/2012 07:06 PM, Stephen Kent wrote:
Below is the text that was briefed in the PKIX meeting yesterday and that represents
the current, proposed text for addition to Section 3.2. Russ noted that we need to
add a reference to the 2008 version of X.509 from which we have cited text.  Peter will
reissue the doc with this change. I plan to forward that version to the IESG a week after
it is posted, unless we hear otherwise.

Could one change  'generate' to 'want to use' ?
TIA


Steve
-----

Add the following paragraph to the end of RFC 5280, Section 3.2:

Consistent with Section 3.4.61 of X.509 (11/2008) we note that use of self-issued certificates and self-signed certificates issued by other than CAs are outside the scope of this specification. Thus, for example, a web server or client might generate a self-signed certificate to identify itself. These certificates, and how a relying party uses them to authenticate asserted identities, are both outside the scope of RFC 5280.




_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--------------090306000503030305050401-- From kent@bbn.com Thu Aug 2 13:03:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAF711E818C for ; Thu, 2 Aug 2012 13:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVLXcCwF3B-s for ; Thu, 2 Aug 2012 13:03:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B9B1211E8186 for ; Thu, 2 Aug 2012 13:03:38 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:48692 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sx1cJ-00063q-6e for pkix@ietf.org; Thu, 02 Aug 2012 16:03:31 -0400 Message-ID: <501ADD12.4050207@bbn.com> Date: Thu, 02 Aug 2012 16:03:30 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: pkix@ietf.org References: <501AB3A3.4020209@bbn.com> <501ABCFB.7040907@edelweb.fr> In-Reply-To: <501ABCFB.7040907@edelweb.fr> Content-Type: multipart/alternative; boundary="------------090707000007070902040401" Subject: Re: [pkix] reminder X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 20:03:39 -0000 This is a multi-part message in MIME format. --------------090707000007070902040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/2/12 1:46 PM, Peter Sylvester wrote: > On 08/02/2012 07:06 PM, Stephen Kent wrote: >> Below is the text that was briefed in the PKIX meeting yesterday and >> that represents >> the current, proposed text for addition to Section 3.2. Russ noted >> that we need to >> add a reference to the 2008 version of X.509 from which we have cited >> text. Peter will >> reissue the doc with this change. I plan to forward that version to >> the IESG a week after >> it is posted, unless we hear otherwise. > > Could one change 'generate' to 'want to use' ? > TIA No. As I noted before, 5280 discusses cert signing (aka generation) and cert processing by an RP. The text above addresses these separately, and appropriately. Steve --------------090707000007070902040401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 8/2/12 1:46 PM, Peter Sylvester wrote:
On 08/02/2012 07:06 PM, Stephen Kent wrote:
Below is the text that was briefed in the PKIX meeting yesterday and that represents
the current, proposed text for addition to Section 3.2. Russ noted that we need to
add a reference to the 2008 version of X.509 from which we have cited text.  Peter will
reissue the doc with this change. I plan to forward that version to the IESG a week after
it is posted, unless we hear otherwise.

Could one change  'generate' to 'want to use' ?
TIA
No. As I noted before, 5280 discusses cert signing (aka generation) and cert processing
by an RP. The text above addresses these separately, and appropriately.

Steve
--------------090707000007070902040401-- From pala@nyu.edu Thu Aug 2 14:43:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C41311E80EA for ; Thu, 2 Aug 2012 14:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz-aTtu3P6Gr for ; Thu, 2 Aug 2012 14:43:47 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC25211E8087 for ; Thu, 2 Aug 2012 14:43:46 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so10959vcb.31 for ; Thu, 02 Aug 2012 14:43:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=1zycKelG/kmxZSzjUklCmmZOVIsqI7kVdeFjUmqKxXk=; b=Q1AubyqwZ3HcYvTWbY6ZAjGTMpMKZ2bvsInK7DUJOPaNcIgw03M9kvIqylGIXAKLVi JHokoBGez5kmGbhj0z1lH9APk/A1iJ29kD8fMOdXmY29WR3ZSDBJtzLFc3mloL2hYzyj iFDu7ITKsLPIEUw5rW+u+fHneMjBET0P8BVgavLZgtTDIjLEiIv/EeUW9voOgYPynZfm ow/inYtPxFuP7vsPPdTreKlMQfXAkISXdgEw8UTDJr4S666LlOwUkRfJefJPvgupLG2p T+YNnsQlxBbJXpEXTl0yEMe2KxP0N8NdTxEhySJMrcDAM+fU4B7FygQFqpvspjK1sL10 Yasw== Received: by 10.58.156.67 with SMTP id wc3mr10483400veb.60.1343943826189; Thu, 02 Aug 2012 14:43:46 -0700 (PDT) Received: from zeus.openca.dyndns.org (zeus.poly.edu. [128.238.102.111]) by mx.google.com with ESMTPS id d11sm6934619vdf.15.2012.08.02.14.43.45 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 14:43:45 -0700 (PDT) Message-ID: <501AF489.4020709@nyu.edu> Date: Thu, 02 Aug 2012 17:43:37 -0400 From: Massimiliano Pala User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: pkix@ietf.org References: <201208021732.q72HW5Jr070976@givry.fdupont.fr> In-Reply-To: <201208021732.q72HW5Jr070976@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnHSmZiLnwMnKVXqAk012ryPiQ7Nj8DLxJ7N16NytCazUwdjgJZccwXvt3hi24hJQfispdJ Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: pala@isis.poly.edu List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:43:48 -0000 Hello Francis, Thanks for the comments - as Scott wrote, it would be interesting if you could let us know what is, specifically, that you do not like and how this could be a problem for PKIs (why it should not be standardized). Our attempt is to provide another mechanism that CAs can use (if they want to) to distribute pre-computed OCSP responses - cheap, easy to deploy, and that would deliver (by using the DNS caching) the response close to the client (thus, enhancing their availability). Issue: - We need to improve the availability of OCSP responses. Today, the quality of service across different CAs is not enough for applications to enable strict revocation checking (issues: costs and connectivity issues (eg., latency)) The starting points for our proposal are: - We should try to provide an infrastructure for OCSP checking (rev info checking) that minimize unavailability of data because of network issues - Pre-computed OCSP responses can be provided via different access methods (e.g., HTTP, CDNs, FTP, etc.) - For high-volume websites, huge bandwidth is required on the OCSP side to provide services that meet the expectations (and high costs) of clients - Availability of OCSP responses could be increased by using widely deployed and distributed services like DNS / DNSSEC Given the problem, the well-defined boundaries, and the considerations on the need to address the availability of revocation information, we think that this I-D could provide a well-targeted mid-term solution to the issue. Any input on the matter that takes in consideration the above points, is more than welcome as the purpose here is to address a real issue that affects practically all the Internet users. Best, Max On 08/02/2012 01:32 PM, Francis Dupont wrote: > In your previous mail you wrote: > >> Time was short and I failed to get further feedback from the folks >> who "hated" (yes that was the exact phrase that was used) the idea >> as to WHY they do not support the idea. > => I attended another session so I didn't follow the presentation itself > but according to the slides in the meeting materials I am afraid I deeply > dislike the idea (i.e., haters++). BTW the DNS is in no way a "transport". > > Regards > > Francis.Dupont@fdupont.fr > (and for this time I am making an exception, fdupont@isc.org too) -- tel.718-260-4009 | web: http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director & Founder, OpenCA Labs Research Professor, NYU Poly Assistant Director, CRISSP http://crissp.poly.edu From stefan@aaa-sec.com Thu Aug 2 15:27:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC74A11E811E for ; Thu, 2 Aug 2012 15:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.009 X-Spam-Level: X-Spam-Status: No, score=-103.009 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPtu3MP0-DCr for ; Thu, 2 Aug 2012 15:27:40 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1539C11E80E1 for ; Thu, 2 Aug 2012 15:27:40 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 984FA2288459 for ; Fri, 3 Aug 2012 00:27:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ekgx7HL4pFuD for ; Fri, 3 Aug 2012 00:27:38 +0200 (CEST) Received: from s331.loopia.se (new-s34.loopia.se [194.9.94.94]) by s87.loopia.se (Postfix) with ESMTP id 57A1D228827A for ; Fri, 3 Aug 2012 00:27:38 +0200 (CEST) Received: (qmail 44472 invoked from network); 2 Aug 2012 22:27:37 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.208]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 2 Aug 2012 22:27:37 -0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Thu, 02 Aug 2012 15:27:35 -0700 From: Stefan Santesson To: Simon Josefsson , Message-ID: Thread-Topic: [pkix] OCSP 2560bis - responderID clarification In-Reply-To: <87sjc6fb20.fsf@latte.josefsson.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] OCSP 2560bis - responderID clarification X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:27:40 -0000 Simon, I fully agree, The spec ought to say something about the expected information if the Name choice is chosen. The ASN.1 structure is defined, but some wording about content would be suitable. I can't see however that anything but the subject name of the OCSP responder (identical to the responder certificate) would go here. /Stefan On 12-08-01 4:27 PM, "Simon Josefsson" wrote: >The semantics of the responderID field is something that may be useful >to clarify in an RFC 2560 document. I brought this up earlier, but it >may have been forgotten in the flurry of other issues: > >http://www.ietf.org/mail-archive/web/pkix/current/msg29802.html >http://www.ietf.org/mail-archive/web/pkix/current/msg29803.html > >One good reason for not clarifying this would be if the intention is >fussy or people are implementing different approaches. Does anyone know >if that is the case? > >/Simon >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From Jeff.Hodges@KingsMountain.com Thu Aug 2 18:22:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B5C21F88CD for ; Thu, 2 Aug 2012 18:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t30H9q-hW5MT for ; Thu, 2 Aug 2012 18:22:38 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 2E39F21F87A8 for ; Thu, 2 Aug 2012 18:22:38 -0700 (PDT) Received: (qmail 9841 invoked by uid 0); 3 Aug 2012 01:22:37 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 3 Aug 2012 01:22:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=9Q9SGJNbsvb+54tjMqnicjSiVO1SoA7HCSBU7alcS00=; b=E4XsUJ5Cy7PY9nWpQcWuWIYOp0E8A/rWWaOksAz8eYRuxt2y0M0lgfjZMLMR3QjV78wgpWyJWkyWF4GWRFWvZ9qbHaXh48kTO2CfZeBexmclvAEUYB6CX8Zh52RQl6Eo; Received: from [130.129.86.152] (port=50423) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Sx6b5-000479-Je; Thu, 02 Aug 2012 19:22:35 -0600 Message-ID: <501B27D8.6020109@KingsMountain.com> Date: Thu, 02 Aug 2012 18:22:32 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: IETF PKIX WG , IETF Security Area Advisory Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.86.152 authed with jeff.hodges+kingsmountain.com} Subject: [pkix] fyi: CA/Browser Forum (CABF) reform deliberations + Revocation and TLS/SSL Replacements/Enhancements X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 01:22:39 -0000 FYI, as I mentioned in the SAAG session this afternoon and have mentioned on these lists before, the CA/Browser Forum (CABF) is entertaining governance reforms. The CABF has decided on four governance proposals on which the members are voting. These proposals are listed on the CABF home page here.. CA/Browser Forum (CABF): Governance Proposals Published, Advancing Toward Adoption http://cabforum.org/ As noted there, the CABF is soliciting public input (but not votes), and as noted in this email message.. CA/Browser Forum Governance Reform Proposals Published ..the deadline for CABF members to vote on the proposals is fast approaching, it is next Wednesday, Aug 8, 2012. So get your comments in! Full Disclosure: One of the four CABF reform proposals is authored by us at PayPal (my employer). We have a recent blog post regarding the governance reform proposals here.. CA/Browser Forum Governance Reform Proposals Published (Brad Hill) I'm here @ietf-84, feel free to reach out if you have any questions, =JeffH From Jeff.Hodges@KingsMountain.com Thu Aug 2 18:44:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D5511E80CC for ; Thu, 2 Aug 2012 18:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XKsYel9wO3y for ; Thu, 2 Aug 2012 18:44:16 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 4C31B11E80A6 for ; Thu, 2 Aug 2012 18:44:16 -0700 (PDT) Received: (qmail 13537 invoked by uid 0); 3 Aug 2012 01:44:16 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 3 Aug 2012 01:44:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=/NxsPfMOsEVfZd0SEMtl33e0inv3YwtPkNwVU31MYy8=; b=vVubcwM3n3erU9ekgVsJhK3MMW+Bl2ReQ3mXKdHylmz78Jr4nsrT80p2EkRbJuqq0EKIfuNenmcVZTm/D03Y1JERRQ+TK4u0weHn9yQOd0Go4q4r8qNMnzUBX+C/++01; Received: from [130.129.86.152] (port=50549) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Sx6w3-0003YC-GS; Thu, 02 Aug 2012 19:44:15 -0600 Message-ID: <501B2CEC.9050508@KingsMountain.com> Date: Thu, 02 Aug 2012 18:44:12 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: IETF PKIX WG , IETF Security Area Advisory Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.86.152 authed with jeff.hodges+kingsmountain.com} Subject: [pkix] fyi: CA/Browser Forum (CABF) reform voting (corrected) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 01:44:17 -0000 [ my apologies, I sent my prior message before it was complete, please forgive me, and see below -- note that there's an updated link to the cabforum public email message discussing the vote ] FYI, as I mentioned in the SAAG session this afternoon and have mentioned on these lists before, the CA/Browser Forum (CABF) is entertaining governance reforms. The CABF has decided on four governance proposals on which the members are voting. These proposals are listed on the CABF home page here.. CA/Browser Forum (CABF): Governance Proposals Published, Advancing Toward Adoption http://cabforum.org/ As noted there, the CABF is soliciting public input (but not votes), and as noted in this email message.. [cabfpub] Replacement Chair and Governance ..the deadline for CABF members to vote on the proposals is fast approaching, it is next Wednesday, Aug 8, 2012. So get your comments in! Full Disclosure: One of the four CABF reform proposals is authored by us at PayPal (my employer). We have a recent blog post regarding the governance reform proposals here.. CA/Browser Forum Governance Reform Proposals Published (Brad Hill) I'm here @ietf-84, feel free to reach out if you have any questions, =JeffH From ajs@anvilwalrusden.com Thu Aug 2 20:47:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9080611E80B8 for ; Thu, 2 Aug 2012 20:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsXuqu47vJf7 for ; Thu, 2 Aug 2012 20:47:47 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id D082F11E80AE for ; Thu, 2 Aug 2012 20:47:47 -0700 (PDT) Received: from crankycanuck.ca (dhcp-473a.meeting.ietf.org [130.129.71.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 18CA08A031 for ; Fri, 3 Aug 2012 03:47:46 +0000 (UTC) Date: Thu, 2 Aug 2012 23:47:40 -0400 From: Andrew Sullivan To: pkix@ietf.org Message-ID: <20120803034740.GA46906@crankycanuck.ca> References: <501AAF29.9030307@DigiCert.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501AAF29.9030307@DigiCert.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 03:47:49 -0000 Dear colleagues, I apologise I had to leave the PKIX meeting yesterday after the CAA discussion; I was double booked. Also, for that reason I wasn't really prepared for PKIX (indeed, it was only due to a fortunate IM that I knew I needed to pay attention. Thanks to Richard!) So, I hadn't read draft-pala-rea-ocsp-over-dns prior to today. I just did, although very quickly. On Thu, Aug 02, 2012 at 10:47:37AM -0600, Scott Rea wrote: > https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/) and > some folks who said they did not like the idea. Time was short and I > failed to get further feedback from the folks who "hated" (yes that > was the exact phrase that was used) the idea as to WHY they do not > support the idea. My natural reaction when someone says, "%$#* that, just put it in the DNS," [http://twitpic.com/9au7p5] is to break out in hives, so I get why people "hate" this proposal. That said, it is not the dumbest idea I've heard. It's not even the dumbest idea I've heard this week. If I understand it correctly, all the data ends up in a DNS zone operated by the CA, and the goal is mainly to produce a mechanism that is low latency and can take advantage of distributed caches. If that's right, then it seems to me like a possibly viable notion. The draft as it stands needs an enormous amount of work, I should note. I have some reservations about the DNS URL arrangement, at least to the extent I understand it (which isn't very far). As it stands, the draft doesn't say at all how to look these records up, nor what RRTYPE they use (I suspect a new one is needed, and we'll need to specify it). Those issues are all just issues about the details in the document, however, and could be fixed. Also, it seems to me that this approach could help with a significant problem that CAs have. There are some environments, of course, in which this approach won't work. I'm nervous about the speed at which a new RRTYPE could be deployed, and that might be a dealbreaker. Also, sometimes applications just can't get unmolested access to DNS, and that might be another problem that means this won't really help. But perhaps these things could be mitigated, and some additional iterations will probably clarify some of it. I am willing to help with the document if the authors want to pursue it. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From dev+ietf@seantek.com Fri Aug 3 00:41:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678E621F8D4E for ; Fri, 3 Aug 2012 00:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBfmktq+yHpJ for ; Fri, 3 Aug 2012 00:41:51 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id F155D21F8D4C for ; Fri, 3 Aug 2012 00:41:47 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.173.239.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4819A509EB for ; Fri, 3 Aug 2012 03:41:41 -0400 (EDT) Message-ID: <501B80B3.4000100@seantek.com> Date: Fri, 03 Aug 2012 00:41:39 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: pkix@ietf.org References: <501AAF29.9030307@DigiCert.com> <20120803034740.GA46906@crankycanuck.ca> In-Reply-To: <20120803034740.GA46906@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 07:41:53 -0000 On 8/2/2012 8:47 PM, Andrew Sullivan wrote: > On Thu, Aug 02, 2012 at 10:47:37AM -0600, Scott Rea wrote: > >> https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/) and >> some folks who said they did not like the idea. Time was short and I >> failed to get further feedback from the folks who "hated" (yes that >> was the exact phrase that was used) the idea as to WHY they do not >> support the idea. > My natural reaction when someone says, "%$#* that, just put it in the > DNS," [http://twitpic.com/9au7p5] is to break out in hives, so I get > why people "hate" this proposal. That said, it is not the dumbest > idea I've heard. It's not even the dumbest idea I've heard this week. > If I understand it correctly, all the data ends up in a DNS zone > operated by the CA, and the goal is mainly to produce a mechanism that > is low latency and can take advantage of distributed caches. If > that's right, then it seems to me like a possibly viable notion. > > For those who were not at the WG meeting, to reiterate a point that was mentioned: There is concern that "just putting it in the DNS" will overload DNS operators. This should be addressed through empirical data, the conclusions based on which ought to be mentioned in the RFC. [Note: it shouldn't overload DNS operators--if they are all under the CA's domain, then it only "overloads" the CA operator, but this should be cheaper than running a true OCSP server. However, it may place more overhead on intervening DNS caching servers, as distinct from DNS operators that have the authoritative records.] > The draft as it stands needs an enormous amount of work, I should > note. I have some reservations about the DNS URL arrangement, at > least to the extent I understand it (which isn't very far). As it > stands, the draft doesn't say at all how to look these records up, nor > what RRTYPE they use (I suspect a new one is needed, and we'll need to > specify it). To iterate a point of my own volition (with a nod to my co-author colleague): http://tools.ietf.org/html/rfc4501 S. Josefsson, Domain Name System Uniform Resource Identifiers Whatever is in ocsp-over-dns must follow RFC 4501, which specifies: dns://192.168.1.1/some.ocsp.ca.service.com?type=SOMETYPE If you have a problem with the format of DNS URIs, it's about six years too late...but at least RFC 4501 provides a comprehensive treatment of that. Sean From simon@josefsson.org Fri Aug 3 01:45:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF1D21F8D7B for ; Fri, 3 Aug 2012 01:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDcVIISIy3lE for ; Fri, 3 Aug 2012 01:45:58 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id BAF8821F8D79 for ; Fri, 3 Aug 2012 01:45:56 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q738jhD1013538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 3 Aug 2012 10:45:44 +0200 From: Simon Josefsson To: Stefan Santesson References: <87sjc6fb20.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120803:stefan@aaa-sec.com::v7vbthaX4HLXz9Vz:4WH6 X-Hashcash: 1:22:120803:pkix@ietf.org::mQ6YC0JifCyt/DMk:3M/c Date: Fri, 03 Aug 2012 10:45:42 +0200 In-Reply-To: (Stefan Santesson's message of "Thu, 02 Aug 2012 15:27:35 -0700") Message-ID: <87pq78bbyh.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: pkix@ietf.org Subject: Re: [pkix] OCSP 2560bis - responderID clarification X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 08:45:58 -0000 Stefan Santesson writes: > Simon, > > I fully agree, > The spec ought to say something about the expected information if the Name > choice is chosen. > > The ASN.1 structure is defined, but some wording about content would be > suitable. > > I can't see however that anything but the subject name of the OCSP > responder (identical to the responder certificate) would go here. Thanks. How about adding something like this to section 4.2.2.3? The purpose of the ResponderID information is to allow clients to find the certificate used to sign a signed OCSP response. Therefor, the information MUST correspond to the certificate that was used to sign the response. It should probably go early in the section, just after the first bullet-point list. I am not confident that this is non-controverisal, as I'm not an OCSP expert. I would appreciate if more people considered whether this text makes sense or not. I am hoping that the paragraph is trivial to everyone experienced with OCSP. When I wrote the OCSP support for GnuTLS I found this area to be under-specified. If there is any deployment out there which puts something other than the OCSP responder signer cert identity in the ResponderID field, I would have expected guidance from the document on what purpose the field serves. The introduction section also needs to be updated to describe this change. I would propose adding something like: o Section 4.2.2.3 clarify that the ResponderID field corresponds to the OCSP Responder signer certificate. Btw, I noticed a typo in the document: OLD: o Section 4.1.1 specifies the ASN.1 syntax for the nonce NEW: o Section 4.4.1 specifies the ASN.1 syntax for the nonce If the XML is available in a respository somewhere, I could send you a patch. :-) Cheers, /Simon From simon@josefsson.org Fri Aug 3 02:09:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C59821F8D38 for ; Fri, 3 Aug 2012 02:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kk4zif0M2eYY for ; Fri, 3 Aug 2012 02:09:34 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6818921F8D1D for ; Fri, 3 Aug 2012 02:09:34 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7399R8r014492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 3 Aug 2012 11:09:28 +0200 X-Hashcash: 1:22:120803:pkix@ietf.org::jjfbWBk+wCliwdnU:ShJZ From: Simon Josefsson To: pkix@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Fri, 03 Aug 2012 11:09:26 +0200 Message-ID: <87lihwbaux.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: [pkix] OCSP algorithm agility: criticality? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 09:09:35 -0000 All, For the RFC2560 update, I reviewed the text copied from RFC 6277 and noticed that it is silent on whether the client extension should or could be marked as critical or not. Is there some guidance on what a client should specify? Is this something that an implementer can chose, or should this be something an administrator or user should be able to specify? I'm guessing that in most situations you would want the extension non-critical, but I wouldn't rule out situations where the client would want to require the OCSP responder to support this extension. Does that reflect what others believe? And finally, does any of these considerations belong in 2560bis? /Simon From eabalea@gmail.com Fri Aug 3 03:08:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB7521F8D72 for ; Fri, 3 Aug 2012 03:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n7Lx4gRfz9d for ; Fri, 3 Aug 2012 03:08:12 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E302B21F8D70 for ; Fri, 3 Aug 2012 03:08:11 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so978468obb.31 for ; Fri, 03 Aug 2012 03:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=szvSA2L+Vms+iJ0ZzcHuiGJ0YHhMnSm6tBCcDIU6TlY=; b=uGshRcmGux3BhX5qLSlZzSzuFGSpwocX8ABr4LlE5VnxYiiZ/Ha7dgvyXEwEP0bC04 4L2IkcPHpHfs6SZ8Dd1tIppcXFAb1LdDdDW56KhHgnnLu5zdamhR36N/+sF4lPUZn2XT L/EpY4xYNTDznYyp0iHOnDIZMPu+DpySpLp89PlIht48RsysAmsM/NLrab+/YtwZP4j+ er3fPtC6/X5b11eTPwLkFVIMgvnhr0KLL5XwBv34HKsneU0dtpGT5YVe5Mwp0ednQ90e lHi+ykuFNM1Q87lftdgqSTBgZ+4BpR/8/va776182/0KMYcYSF9/Yl7180iKxYL/fJlj eKiw== MIME-Version: 1.0 Received: by 10.182.216.99 with SMTP id op3mr3238863obc.30.1343988491395; Fri, 03 Aug 2012 03:08:11 -0700 (PDT) Received: by 10.182.55.227 with HTTP; Fri, 3 Aug 2012 03:08:11 -0700 (PDT) In-Reply-To: <501AF6DC.6050309@nyu.edu> References: <501ADFAC.50302@nyu.edu> <501AF6DC.6050309@nyu.edu> Date: Fri, 3 Aug 2012 12:08:11 +0200 Message-ID: From: Erwann Abalea To: pala@isis.poly.edu Content-Type: multipart/alternative; boundary=f46d044786e79ca32504c659b442 Cc: pkix@ietf.org Subject: Re: [pkix] draft-pala-rea-ocsp-over-dns X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 10:08:13 -0000 --f46d044786e79ca32504c659b442 Content-Type: text/plain; charset=UTF-8 [Sending this to pkix@ietf too, as others might have ideas. I mentionned the fact that nothing permitted to specify parameters along with the hash function, and I'm seeing GOST-hashed OCSP requests in our responders since mid july] Bonjour, I'm not sure that DNSSEC is useful here. After all, OCSP is usually requested and sent in clear, the response is already signed. I don't know what could DNSSEC add in here that we're missing. GOST (and not Ghost) R 34.11-94 is a hash algorithm based on the GOST 28147-89 block cipher. The former needs an initial value, the latter needs some S-Boxes. CryptoPro defined 2 sets of parameters (test and production) in RFC4357, and a NULL parameter designates the "production" parameters (if I correctly read the ASN.1 module, I'm not sure it's valid). There's no "DEFAULT" in the DigestAlgorithm definition, the parameters element is only declared "OPTIONAL", so no value is not a synonym of a NULL value. 2012/8/2 Massimiliano Pala > Hello, > > thanks for the clarification. I agree that an update for RFC4501 is not > the best idea (although it does not give > the possibility to even specify dns vs dnssec, AFAIK). > > For the Ghost.. I see your point. I thought that the ghost hash did not > need parameters to be specified (is there > a default or you have to explicitly specify them all the time ?). That is > an issue as specifying those types of > parameters might be unfeasible in a URI... for that, we might need to > specify an additional extension to cover > that case. It might be the only possibility.. although I am sure people on > the PKIX will just say "no" to another > extension.. > > Thanks again for the input. > > Cheers, > Max > > > > On 08/02/2012 05:44 PM, Erwann Abalea wrote: > >> >> Bonsoir, >> >> Updating RFC4501 to add non-DNS information such as a hash algorithm is >> not a good idea, IMO. Unfortunately, accessLocation in the AIA extension is >> only a GeneralNames type, which leaves no place for a hash algorithm >> either. Some magic trick is necessary. >> >> Regarding GOST, you've added some crypto-agility by allowing the CA to >> specify the hash algorithm to use when hashing the certificate. What is >> proposed is sufficient for classical algorithms (such as the SHA1/2 >> family), because these don't need any parameter. Russia is pushing for its >> set of GOST defined algorithms (block cipher, hash, signature), and these >> algorithms are mandatory in Russia (and maybe neighbours). Support for them >> have been added in DNSSEC, for example. >> The fact is that the GOST block cipher and hash algo (built on top of >> block cipher) need some parameters. For the block cipher, the S-boxes; for >> the hash, the underlying block cipher S-boxes and an IV (initial internal >> state of the hash function). When used in a certificate, these parameters >> find their place in the AlgorithmIdentifier structure (with the SHA* >> families, parameters is set to NULL). >> In your scheme, there's no place for parameters. So crypto-agility is not >> complete. >> I agree that GOST crypto stuff sucks, but we have to deal with real world >> constraints :( >> Anyways, who knows how will the soon-to-be-announced SHA3 be used? Maybe >> it'll also need parameters too? >> > -- Erwann. --f46d044786e79ca32504c659b442 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [Sending this to pkix@ietf too, as others might have ideas. I mentionned th= e fact that nothing permitted to specify parameters along with the hash fun= ction, and I'm seeing GOST-hashed OCSP requests in our responders since= mid july]

Bonjour,

I'm not sure that DNSS= EC is useful here. After all, OCSP is usually requested and sent in clear, = the response is already signed. I don't know what could DNSSEC add in h= ere that we're missing.

GOST (and not Ghost) R 34.11-94 is a hash algorithm bas= ed on the GOST 28147-89 block cipher. The former needs an initial value, th= e latter needs some S-Boxes. CryptoPro defined 2 sets of parameters (test a= nd production) in RFC4357, and a NULL parameter designates the "produc= tion" parameters (if I correctly read the ASN.1 module, I'm not su= re it's valid). There's no "DEFAULT" in the DigestAlgorit= hm definition, the parameters element is only declared "OPTIONAL"= , so no value is not a synonym of a NULL value.

2012/8/2 Massimiliano Pala <pala@nyu.edu>
Hello,

thanks for the clarification. I agree that an update for RFC4501 is not the= best idea (although it does not give
the possibility to even specify dns vs dnssec, AFAIK).

For the Ghost.. I see your point. I thought that the ghost hash did not nee= d parameters to be specified (is there
a default or you have to explicitly specify them all the time ?). That is a= n issue as specifying those types of
parameters might be unfeasible in a URI... for that, we might need to speci= fy an additional extension to cover
that case. It might be the only possibility.. although I am sure people on = the PKIX will just say "no" to another
extension..

Thanks again for =C2=A0the input.

Cheers,
Max



On 08/02/2012 05:44 PM, Erwann Abalea wrote:

Bonsoir,

Updating RFC4501 to add non-DNS information such as a hash algorithm is not= a good idea, IMO. Unfortunately, accessLocation in the AIA extension is on= ly a GeneralNames type, which leaves no place for a hash algorithm either. = Some magic trick is necessary.

Regarding GOST, you've added some crypto-agility by allowing the CA to = specify the hash algorithm to use when hashing the certificate. What is pro= posed is sufficient for classical algorithms (such as the SHA1/2 family), b= ecause these don't need any parameter. Russia is pushing for its set of= GOST defined algorithms (block cipher, hash, signature), and these algorit= hms are mandatory in Russia (and maybe neighbours). Support for them have b= een added in DNSSEC, for example.
The fact is that the GOST block cipher and hash algo (built on top of block= cipher) need some parameters. For the block cipher, the S-boxes; for the h= ash, the underlying block cipher S-boxes and an IV (initial internal state = of the hash function). When used in a certificate, these parameters find th= eir place in the AlgorithmIdentifier structure (with the SHA* families, par= ameters is set to NULL).
In your scheme, there's no place for parameters. So crypto-agility is n= ot complete.
I agree that GOST crypto stuff sucks, but we have to deal with real world c= onstraints :(
Anyways, who knows how will the soon-to-be-announced SHA3 be used? Maybe it= 'll also need parameters too?
=

--
Erwann.
--f46d044786e79ca32504c659b442-- From ajs@anvilwalrusden.com Fri Aug 3 03:29:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0B121F8D98 for ; Fri, 3 Aug 2012 03:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeMJWjDPzYEL for ; Fri, 3 Aug 2012 03:29:46 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5807521F8D8E for ; Fri, 3 Aug 2012 03:29:46 -0700 (PDT) Received: from mail.yitter.info (dhcp-473a.meeting.ietf.org [130.129.71.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id AC8C58A031 for ; Fri, 3 Aug 2012 10:29:44 +0000 (UTC) Date: Fri, 3 Aug 2012 06:29:42 -0400 From: Andrew Sullivan To: pkix@ietf.org Message-ID: <20120803102942.GD47780@mail.yitter.info> References: <501AAF29.9030307@DigiCert.com> <20120803034740.GA46906@crankycanuck.ca> <501B80B3.4000100@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501B80B3.4000100@seantek.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 10:29:47 -0000 On Fri, Aug 03, 2012 at 12:41:39AM -0700, Sean Leonard wrote: > > There is concern that "just putting it in the DNS" will overload DNS > operators. This should be addressed through empirical data, the > conclusions based on which ought to be mentioned in the RFC. I don't see how this could overload a DNS operator. But anyway, that's a rather unconvincing argument, for taken to its logical conclusion it would preclude putting anything more in the DNS. Given that the proposal puts everything into a single zone (well, one or more zones per CA, but anyway it uses the normal top-down DNS lookup model), I simply don't see any objection on operational grounds, unless the responses are very large (that would have implications for caches). > To iterate a point of my own volition (with a nod to my co-author > colleague): > > http://tools.ietf.org/html/rfc4501 > S. Josefsson, Domain Name System Uniform Resource Identifiers > > Whatever is in ocsp-over-dns must follow RFC 4501, which specifies: > dns://192.168.1.1/some.ocsp.ca.service.com?type=SOMETYPE Yeah, that was more or less what I was expecting, and the draft doesn't look to my bleary eyes like it's following that. It also doesn't refer to RFC 4501, so I think that might be the first problem. I'm more concerned about the RRTYPE and responses, though, for the reasons above. Fixing up the way the URI is presented would be irrelevant if we learn that every response is going to be 400k. I'm pretty sure that's not the case, but I can't tell from the draft. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Fri Aug 3 03:45:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E594421F8DB1 for ; Fri, 3 Aug 2012 03:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKANo9gDUktX for ; Fri, 3 Aug 2012 03:45:51 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5F88821F8DAE for ; Fri, 3 Aug 2012 03:45:51 -0700 (PDT) Received: from mail.yitter.info (dhcp-473a.meeting.ietf.org [130.129.71.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id AF94E8A031 for ; Fri, 3 Aug 2012 10:45:50 +0000 (UTC) Date: Fri, 3 Aug 2012 06:45:48 -0400 From: Andrew Sullivan To: pkix@ietf.org Message-ID: <20120803104548.GF47780@mail.yitter.info> References: <501ADFAC.50302@nyu.edu> <501AF6DC.6050309@nyu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] draft-pala-rea-ocsp-over-dns X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 10:45:52 -0000 On Fri, Aug 03, 2012 at 12:08:11PM +0200, Erwann Abalea wrote: > I'm not sure that DNSSEC is useful here. After all, OCSP is usually > requested and sent in clear, the response is already signed. I don't know > what could DNSSEC add in here that we're missing. I don't fully understand the way the mechanism is supposed to work, and I don't really know very much about OCSP, so I'm speaking from almost total ignorance. But DNSSEC will provide you with assurances that the answer you get is in fact unmolested along the path. This could be important for ensuring you don't get fake answers. For instance, without DNSSEC, an attacker could insert an Name Error response and thereby leave the client needing to fall back to some other mechanism. In the presence of DNSSEC, that attack would be detected. (You'd still be unable to use the mechanism, so I can see an argument that there's no real gain here.) >From the draft, however, I have no idea how the response is signed when it comes through the DNS. Am I just overlooking something in the draft? Since there's no RRTYPE definition, it's kinda hard to know what the fields in the response will contain. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From eabalea@gmail.com Fri Aug 3 06:01:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E4D21F8D6B for ; Fri, 3 Aug 2012 06:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TOxvLjfm5Gi for ; Fri, 3 Aug 2012 06:01:38 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 922A421F8D1C for ; Fri, 3 Aug 2012 06:01:38 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1208929obb.31 for ; Fri, 03 Aug 2012 06:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jxE6bPR1NgW7ckIjpgQ0EvdB9uN1cyjJxWOiOoAIQtU=; b=OzJ7jN+M9jgDsmvdIYR9x/ARrMoAW3OWdZbVKQzhWOapDI68+sH7tcleUZR3RE1GsA 2aDYD56+TwabAdJ2sGOT8ECrCrO4ZTC8Lm5oasBY/8yzmKGSmUu7uQ90sXsGEwmmd8y9 NQbdK2hPW3hhiFPa7wJffJWwXOln5zfZSjkeqizzzUoPLhlRtOKY2fKVAT+UAU5eKd7Z cdpe2ocgfBw3OjV76+MzcMsPpQCCry0ADy8pBRBtEo1rGLTyXH4lyFwTt3h2YmCiHVhr BxPuePAhJHms4RSINIyJcFsYwK4KMflKMO+epm4K+aM3GMpWmxc3Z/mcj2GIYH2KOPN/ w7IQ== MIME-Version: 1.0 Received: by 10.182.212.36 with SMTP id nh4mr4455696obc.37.1343998898125; Fri, 03 Aug 2012 06:01:38 -0700 (PDT) Received: by 10.182.55.227 with HTTP; Fri, 3 Aug 2012 06:01:38 -0700 (PDT) In-Reply-To: <20120803104548.GF47780@mail.yitter.info> References: <501ADFAC.50302@nyu.edu> <501AF6DC.6050309@nyu.edu> <20120803104548.GF47780@mail.yitter.info> Date: Fri, 3 Aug 2012 15:01:38 +0200 Message-ID: From: Erwann Abalea To: Andrew Sullivan Content-Type: multipart/alternative; boundary=e89a8f642902e6bae304c65c20b5 Cc: pkix@ietf.org Subject: Re: [pkix] draft-pala-rea-ocsp-over-dns X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 13:01:39 -0000 --e89a8f642902e6bae304c65c20b5 Content-Type: text/plain; charset=UTF-8 2012/8/3 Andrew Sullivan > On Fri, Aug 03, 2012 at 12:08:11PM +0200, Erwann Abalea wrote: > > > I'm not sure that DNSSEC is useful here. After all, OCSP is usually > > requested and sent in clear, the response is already signed. I don't know > > what could DNSSEC add in here that we're missing. > > I don't fully understand the way the mechanism is supposed to work, > and I don't really know very much about OCSP, so I'm speaking from > almost total ignorance. But DNSSEC will provide you with assurances > that the answer you get is in fact unmolested along the path. This is already guaranteed with OCSP, which are signed objects. > This > could be important for ensuring you don't get fake answers. For > instance, without DNSSEC, an attacker could insert an Name Error > response and thereby leave the client needing to fall back to some > other mechanism. In the presence of DNSSEC, that attack would be > detected. (You'd still be unable to use the mechanism, so I can see > an argument that there's no real gain here.) > That's the point. DNSSEC offers nothing more. Today's mechanism: - attacker exchanges the response with a one unrelated to the request: RP can detect it - attacker exchanges the response with a previous one: RP can detect if the response has expired, responses usually have a max 10 days validity period, some CAs have 4 hours validity responses - attacker exchanges the response with an unsigned error message: RP can detect it - attacker blocks the response: RP can detect it When the RP detects something wrong, it either falls back to another validation mechanism (other OCSP URL, or CRL) or declares the certificate as not trusted. With the proposed mechanism (DNS), DNSSEC could have some value on the second example, but then the attacker could simply block the response and let the RP rely on a CRL and the attack still applies. >From the draft, however, I have no idea how the response is signed > when it comes through the DNS. Am I just overlooking something in the > draft? Since there's no RRTYPE definition, it's kinda hard to know > what the fields in the response will contain. > What I understand is that the returned object is the requested OCSP token, not a different beast. -- Erwann. --e89a8f642902e6bae304c65c20b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/8/3 Andrew Sullivan &= lt;ajs@anvilwal= rusden.com>
On Fri, Aug 03, 2012 at 12:08:11PM +0200, Erwann Abalea w= rote:

> I'm not sure that DNSSEC is useful here. After all, OCSP is usuall= y
> requested and sent in clear, the response is already signed. I don'= ;t know
> what could DNSSEC add in here that we're missing.

I don't fully understand the way the mechanism is supposed to wor= k,
and I don't really know very much about OCSP, so I'm speaking from<= br> almost total ignorance. =C2=A0But DNSSEC will provide you with assurances that the answer you get is in fact unmolested along the path.
=

This is already guaranteed with OCSP, which are signed = objects.
=C2=A0
=C2=A0This
could be important for ensuring you don't get fake answers. =C2=A0For instance, without DNSSEC, an attacker could insert an Name Error
response and thereby leave the client needing to fall back to some
other mechanism. =C2=A0In the presence of DNSSEC, that attack would be
detected. =C2=A0(You'd still be unable to use the mechanism, so I can s= ee
an argument that there's no real gain here.)

<= /div>
That's the point. DNSSEC offers nothing more.

<= /div>
Today's mechanism:
=C2=A0- attacker exchanges the r= esponse with a one unrelated to the request: RP can detect it
=C2=A0- attacker exchanges the response with a previous one: RP can de= tect if the response has expired, responses usually have a max 10 days vali= dity period, some CAs have 4 hours validity responses
=C2=A0- att= acker exchanges the response with an unsigned error message: RP can detect = it
=C2=A0- attacker blocks the response: RP can detect it

<= /div>
When the RP detects something wrong, it either falls back to anot= her validation mechanism (other OCSP URL, or CRL) or declares the certifica= te as not trusted.

With the proposed mechanism (DNS), DNSSEC could have so= me value on the second example, but then the attacker could simply block th= e response and let the RP rely on a CRL and the attack still applies.

From the draft, however, I ha= ve no idea how the response is signed
when it comes through the DNS. =C2=A0Am I just overlooking something in the=
draft? =C2=A0Since there's no RRTYPE definition, it's kinda hard to= know
what the fields in the response will contain.

What I understand is that the returned object is the requested OCSP = token, not a different beast.

--
Erwann.
--e89a8f642902e6bae304c65c20b5-- From Francis.Dupont@fdupont.fr Fri Aug 3 09:15:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B7521F8E1D for ; Fri, 3 Aug 2012 09:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC4N15wHg3p1 for ; Fri, 3 Aug 2012 09:15:33 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 750E421F8D45 for ; Fri, 3 Aug 2012 09:15:33 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q73GFCEa055158; Fri, 3 Aug 2012 18:15:12 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201208031615.q73GFCEa055158@givry.fdupont.fr> From: Francis Dupont To: Erwann Abalea In-reply-to: Your message of Fri, 03 Aug 2012 15:01:38 +0200. Date: Fri, 03 Aug 2012 18:15:12 +0200 Sender: Francis.Dupont@fdupont.fr Cc: pkix@ietf.org Subject: Re: [pkix] draft-pala-rea-ocsp-over-dns X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 16:15:34 -0000 In your previous mail you wrote: > This is already guaranteed with OCSP, which are signed objects. > > That's the point. DNSSEC offers nothing more. => not formally 100% true: DNSSEC offers secured proof of not existence. Now IMHO it doesn't change things for this intented (mis)use of DNS, so DNSSEC should only increase the size of responses... Regards Francis.Dupont@fdupont.fr PS: my reasoning is to get a such name or RR doesn't exist response *or* no response won't really make a difference. From pala@isis.poly.edu Fri Aug 3 10:32:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9774621F8D60 for ; Fri, 3 Aug 2012 10:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UlFCDJSYIAh for ; Fri, 3 Aug 2012 10:32:36 -0700 (PDT) Received: from isis.poly.edu (isis.poly.edu [128.238.66.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2806D21F8D63 for ; Fri, 3 Aug 2012 10:32:35 -0700 (PDT) Received: (qmail 69245 invoked from network); 3 Aug 2012 17:32:31 -0000 Received: from unknown (HELO zeus.openca.dyndns.org) (madwolf@68.45.183.116) by isis.poly.edu with CAMELLIA256-SHA encrypted SMTP; 3 Aug 2012 17:32:31 -0000 Message-ID: <501C0B15.4000700@isis.poly.edu> Date: Fri, 03 Aug 2012 13:32:05 -0400 From: Massimiliano Pala Organization: NYU Poly User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: pkix@ietf.org References: <501AAF29.9030307@DigiCert.com> <20120803034740.GA46906@crankycanuck.ca> <501B80B3.4000100@seantek.com> In-Reply-To: <501B80B3.4000100@seantek.com> Content-Type: multipart/alternative; boundary="------------070303030007070400010803" Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: pala@isis.poly.edu List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:32:38 -0000 This is a multi-part message in MIME format. --------------070303030007070400010803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/03/2012 03:41 AM, Sean Leonard wrote: > [...] There is concern that "just putting it in the DNS" will > overload DNS operators. This should be addressed through empirical > data, the conclusions based on which ought to be mentioned in the > RFC. > > [Note: it shouldn't overload DNS operators--if they are all under the > CA's domain, then it only "overloads" the CA operator, but this > should be cheaper than running a true OCSP server. However, it may > place more overhead on intervening DNS caching servers, as distinct > from DNS operators that have the authoritative records.] > This has been an argument that has been present since... 10yrs ago. In general, I would agree that you should not overload the DNS (e.g., using DNS to distribute any type of certificates - like user certs - bad idea), however I also think that the scope we identified is very well defined and that will *NOT overload the DNS at all*. Also, since these responses go through DNS, it might solve the problem with some environments (e.g., web-portals) where traffic toward OCSP servers might be blocked - usually DNS lookups are enabled in that environment. This would help to enable revocation checking also before having complete access to the net - e.g., revocation checking might be enabled also in hotel-like portal access. [...] > To iterate a point of my own volition (with a nod to my co-author > colleague): > > http://tools.ietf.org/html/rfc4501 S. Josefsson, Domain Name System > Uniform Resource Identifiers I think that you (and some others in the list) are missing the point that we need to specify a bit more than just a URI. There are several problems with the RFC 4501 to be used in this proposal. Keep in mind that the RFC is meant to specify DNS URIs, but it does not cover the fact that we need to specify additional information that the client MUST use to build the final URL. In particular, we can not use RFC 4501 URLs because of two important points (I guess this will put an end to this discussion on using RFC 4501): - RFC 4501 does not allow to specify dns vs dnssec. If an operator wants to convey that the returned DNS response WILL be signed, if the URL does not carry that information, the client can not tell if the received response should be signed or not. As it was said in another message, DNSSEC can guarantee the non-existance of the record, i.e. if a record is not found and the response is correctly signed, the client will know that it has to use another source. On the other hand, if a record should be signed, but a non-signed record is received, this is a source of attack and should be treated as such. - In order to identify the certificate that needs to be checked, the client has to use an hash function to build the DNS entry that should be looked up for. We have two options here. Either we stick with one algorithm (default) as we did in the past for most algorithms (but this would violate the "algorithm-agility" principle), or have a way to specify different algorithms so that the client knows what to use when building the DNS URI. If we go with the second route (which I think we should) we need to be able to specify the algorithm. RFC 4501 is to be used to extract DNS records, and works fine for that, however we need to be able to specify the algorithm. We still have not addresses if we want to be able to provide the possibility to pass also additional parameters that are specific for the algorithm (as pointed out in another email the GOST hash is one of those algorithm that requires additional parameters). These two reasons make RFC 4501 *not suitable* to specify DNS URI for OCSP responses because we need to provide information on how to get to the final URL. Why can't we just specify the full address of the certificate in the DNS URI ? The answer is simple: you don't have the final DER representation of the certificate until the CA has signed it, so you can not include that value in the certificate to be signed. The only workaround to this would be if we use a hash of the serial number to be pre-pended to the domain the CA is managing - however I would suggest against it as this might also be an issue with some CA software (the serial number might be assigned randomly at signing time and changes to the software might be required - a static approach would be easier to deploy). Last but not least, the final I-D could also provide the possibility to specify multiple supported algorithms (eg., future transitions among algorithms). Also in this case RFC 4501 would not provide a suitable solution for that. Cheers, -- tel.718-260-4009 | web: http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director & Founder, OpenCA Labs Research Professor, NYU Poly Assistant Director, CRISSP http://crissp.poly.edu --------------070303030007070400010803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/03/2012 03:41 AM, Sean Leonard wrote:
> [...] There is concern that "just putting it in the DNS" will
> overload DNS operators. This should be addressed through empirical
> data, the conclusions based on which ought to be mentioned in the
> RFC.
>
> [Note: it shouldn't overload DNS operators--if they are all under the
> CA's domain, then it only "overloads" the CA operator, but this
> should be cheaper than running a true OCSP server. However, it may
> place more overhead on intervening DNS caching servers, as distinct
> from DNS operators that have the authoritative records.]
>

This has been an argument that has been present since... 10yrs ago.
In general, I would agree that you should not overload the DNS (e.g., using
DNS to distribute any type of certificates - like user certs - bad idea),
however I also think that the scope we identified is very well defined and
that will *NOT overload the DNS at all*.

Also, since these responses go through DNS, it might solve the problem with
some environments (e.g., web-portals) where traffic toward OCSP servers
might be blocked - usually DNS lookups are enabled in that environment.

This would help to enable revocation checking also before having complete
access to the net - e.g., revocation checking might be enabled also in hotel-like
portal access.

[...]
> To iterate a point of my own volition (with a nod to my co-author
> colleague):
>
> http://tools.ietf.org/html/rfc4501 S. Josefsson, Domain Name System
> Uniform Resource Identifiers

I think that you (and some others in the list) are missing the point that we need to specify
a bit more than just a URI.

There are several problems with the RFC 4501 to be used in this proposal. Keep in mind that
the RFC is meant to specify DNS URIs, but it does not cover the fact that we need to specify
additional information that the client MUST use to build the final URL. In particular, we can not
use RFC 4501 URLs because of two important points (I guess this will put an end to this
discussion on using RFC 4501):

- RFC 4501 does not allow to specify dns vs dnssec. If an operator wants to convey that the
  returned DNS response WILL be signed, if the URL does not carry that information, the client
  can not tell if the received response should be signed or not.

  As it was said in another message, DNSSEC can guarantee the non-existance of the record, i.e.
  if a record is not found and the response is correctly signed, the client will know that it has to
  use another source. On the other hand, if a record should be signed, but a non-signed record
  is received, this is a source of attack and should be treated as such.

- In order to identify the certificate that needs to be checked, the client has to use an hash
  function to build the DNS entry that should be looked up for. We have two options here.
  Either we stick with one algorithm (default) as we did in the past for most algorithms (but
  this would violate the "algorithm-agility" principle), or have a way to specify different algorithms
  so that the client knows what to use when building  the DNS URI. If we go with the second
  route (which I think we should) we need to be able to specify the algorithm. RFC 4501 is to
  be used to extract DNS records, and works fine for that, however we need to be able to specify
  the algorithm. We still have not addresses if we want to be able to provide the possibility to pass
  also additional parameters that are specific for the algorithm (as pointed out in another email
  the GOST hash is one of those algorithm that requires additional parameters).

These two reasons make RFC 4501 *not suitable* to specify DNS URI for OCSP responses because
we need to provide information on how to get to the final URL.

Why can't we just specify the full address of the certificate in the DNS URI ? The answer is simple:
you don't have the final DER representation of the certificate until the CA has signed it, so you can
not include that value in the certificate to be signed.

The only workaround to this would be if we use a hash of the serial number to be pre-pended to
the domain the CA is managing - however I would suggest against it as this might also be an issue
with some CA software (the serial number might be assigned randomly at signing time and changes
to the software might be required - a static approach would be easier to deploy).

Last but not least, the final I-D could also provide the possibility to specify multiple supported algorithms
(eg., future transitions among algorithms). Also in this case RFC 4501 would not provide a suitable
solution for that.

Cheers,

--

tel.718-260-4009 | web: http://member.acm.org/~openca/

Massimiliano Pala, Ph.D.
Director & Founder, OpenCA Labs
Research Professor, NYU Poly
Assistant Director, CRISSP

http://crissp.poly.edu

--------------070303030007070400010803-- From agl@google.com Fri Aug 3 10:40:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB25721F8D1E for ; Fri, 3 Aug 2012 10:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkBKsd3YO7-i for ; Fri, 3 Aug 2012 10:40:11 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94A3721F8D1D for ; Fri, 3 Aug 2012 10:40:11 -0700 (PDT) Received: by yhq56 with SMTP id 56so1229009yhq.31 for ; Fri, 03 Aug 2012 10:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=iJS2CaDRe/EC1QbfvSKN+G8X1okgdsuwmHdJPuGf1og=; b=VPptSd5cIyzG1R9JHZT0iRnNArJT22OEIpc1MEfbgJiZTfn4k6xB345UbeAcbVRLAA sacszO76H7bD0tmeX96HQTBtdNzAK4bR1792ge+ZujyC9MZKqLwWRh+FNl+EASsAZpd9 +2k/dyMMhj+CPc3WHwEFYorcJ9u0Yd/1PWbrvLVrmjnVz/hb0XPiAF+umFHx0Ibv6EDk Ey/2cYLWBg8GyUkKkiJOv0tNw8Yfjt7e3CakwUMFl2MLyjO0Sx4YSnpBm/PzsLbsH97D S/Y17C1xj6JT+yj2Kcji+DcxzYXLAZ218GQlGtJLUweY0YaHCxy3OzoLrPFTHz+2mUHn bTyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=iJS2CaDRe/EC1QbfvSKN+G8X1okgdsuwmHdJPuGf1og=; b=mkS8z6s9zJFc/KnzxizTbhZy12ea9EvlLxV+zzw6dlRkKK70yIZIZpirIoL95zr1X4 9ZaxPuZggRbYnYomE/wC0+ig7orUqFTjSff5rfuT8Av+o42mEjyDhsl01/4FLH1aahSG w+/F5beXQH3b9tlJlF2cl6EtSItN0MdsgRjZlfNAP1hqqJZ7VKc/7XVAVlOk56aVnzOs hUBZahQaOUfa786IxbOtoGQsxI47q676OcDsjfWHVlOrKUhdv2zT9qxZFAGdikjbWHtR FEV4x4+RUvkqVwBrR9vIZNBHHU4x/HLO/CpKVvV/AsWDcVYty4wW+/rKpvU2DZXHkABO 6lcw== Received: by 10.50.202.68 with SMTP id kg4mr4678935igc.43.1344015610145; Fri, 03 Aug 2012 10:40:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.202.68 with SMTP id kg4mr4678918igc.43.1344015609960; Fri, 03 Aug 2012 10:40:09 -0700 (PDT) Received: by 10.231.69.2 with HTTP; Fri, 3 Aug 2012 10:40:09 -0700 (PDT) In-Reply-To: <501C0B15.4000700@isis.poly.edu> References: <501AAF29.9030307@DigiCert.com> <20120803034740.GA46906@crankycanuck.ca> <501B80B3.4000100@seantek.com> <501C0B15.4000700@isis.poly.edu> Date: Fri, 3 Aug 2012 13:40:09 -0400 Message-ID: From: Adam Langley To: pala@isis.poly.edu Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlc3EQDRU8VvW8701CVLqr/6+7ziE0plbhFduEETDbHQEjn0k2A3zZ0eY4nk0UXCUyAQx1xsXXxxKUZhputvsje8sVXkQhkVRTljCZo47Tp2k89e8dLXquQTqTLh+NAlzG8dfeUB89IKtjdMU/m1WogdAKZ9er+SkgtJ9a3XXoBQOleLAnkLdBL5lcns9JNCwLzusbZ Cc: pkix@ietf.org Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:40:13 -0000 I conducted an experiment for testing the viability of wide-spread OCSP over DNS with Chrome. Please see the writeup below, although note that it was conducted some months ago and so words like "today" don't actually mean that. ----- * This has only been enabled in Canary and Dev channels. These channels have users who have opted in to running unstable versions of Chrome and so are not representative in some ways. Setup: For each HTTP request, we consider if it meets all of the following criteria: 1) The request went over HTTPS 2) The reply didn't come from the Chrome cache 3) The certificate rooted at a known public root (i.e. the connection was not MITMed with a user-installed CA cert) 4) The certificate chain passed through at least one of the following: AAACertificateServices AddTrustClass1CARoot AddTrustExternalCARoot AddTrustPublicCARoot AddTrustQualifiedCARoot COMODOCertificationAuthority SecureCertificateServices TrustedCertificateServices UTNDATACorpSGC UTNUSERFirstClientAuthenticationandEmail UTNUSERFirstHardware UTNUSERFirstObject 5) It was more than 10 minutes since the last time we tried a DNS lookup for this experiment. If we find a qualifing HTTP request then we issue a TXT lookup for "wibble.comodoca.com" via the system's resolver library. If the DNS reply comes back in under 10 milliseconds, then we consider it a local cache hit and discard it. (We have an in-process cache as well as any system cache.) Any remaining replies are considered a `success' if the system resolver returned successfully and we find the string "wibble" in the RR data payload. Otherwise they are considered a `failure'. The time taken for the resolution is recorded for both `success' and `failure' responses. Recorded time values are capped to 10 seconds. Results: As of today we have 71,833 successes recorded. The distribution looks as expected: a big hump with a fat right tail. The median is 95ms, 90% at 533ms, 99% at 5961ms. We also have 3,537 failures recorded. 84.7% of these have times > 10s. There is also a 3.5% peak at 3s (i.e. 3 attempts with a one second retry). The remaining ~10% is scattered mostly uniformly. Conclusions: The median is a lot better than an OCSP reponse (which is 268ms at the moment), but the failure rate (4.7%) is very high. ----- Cheers AGL From pala@isis.poly.edu Fri Aug 3 10:41:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6327521F8DE3 for ; Fri, 3 Aug 2012 10:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfl2WxKbXblL for ; Fri, 3 Aug 2012 10:41:02 -0700 (PDT) Received: from isis.poly.edu (isis.poly.edu [128.238.66.15]) by ietfa.amsl.com (Postfix) with ESMTP id 06D8421F8D1E for ; Fri, 3 Aug 2012 10:41:01 -0700 (PDT) Received: (qmail 69473 invoked from network); 3 Aug 2012 17:40:49 -0000 Received: from unknown (HELO zeus.openca.dyndns.org) (madwolf@68.45.183.116) by isis.poly.edu with CAMELLIA256-SHA encrypted SMTP; 3 Aug 2012 17:40:49 -0000 Message-ID: <501C0D19.8010502@isis.poly.edu> Date: Fri, 03 Aug 2012 13:40:41 -0400 From: Massimiliano Pala Organization: NYU Poly User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: pkix@ietf.org References: <201208021732.q72HW5Jr070976@givry.fdupont.fr> In-Reply-To: <201208021732.q72HW5Jr070976@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: pala@isis.poly.edu List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:41:04 -0000 Hello Francis, Thanks for the comments - as Scott wrote, it would be interesting if you could let us know what is, specifically, that you do not like and how this could be a problem for PKIs (why it should not be standardized). Our attempt is to provide another mechanism that CAs can use (if they want to) to distribute pre-computed OCSP responses - cheap, easy to deploy, and that would deliver (by using the DNS caching) the response close to the client (thus, enhancing their availability). Issue: - We need to improve the availability of OCSP responses. Today, the quality of service across different CAs is not enough for applications to enable strict revocation checking (issues: costs and connectivity issues (eg., latency)) The starting points for our proposal are: - We should try to provide an infrastructure for OCSP checking (rev info checking) that minimize unavailability of data because of network issues - Pre-computed OCSP responses can be provided via different access methods (e.g., HTTP, CDNs, FTP, etc.) - For high-volume websites, huge bandwidth is required on the OCSP side to provide services that meet the expectations (and high costs) of clients - Availability of OCSP responses could be increased by using widely deployed and distributed services like DNS / DNSSEC Given the problem, the well-defined boundaries, and the considerations on the need to address the availability of revocation information, we think that this I-D could provide a well-targeted mid-term solution to the issue. Any input on the matter that takes in consideration the above points, is more than welcome as the purpose here is to address a real issue that affects practically all the Internet users. Best, Max On 08/02/2012 01:32 PM, Francis Dupont wrote: > In your previous mail you wrote: > >> Time was short and I failed to get further feedback from the folks >> who "hated" (yes that was the exact phrase that was used) the idea >> as to WHY they do not support the idea. > => I attended another session so I didn't follow the presentation itself > but according to the slides in the meeting materials I am afraid I deeply > dislike the idea (i.e., haters++). BTW the DNS is in no way a "transport". > > Regards > > Francis.Dupont@fdupont.fr > (and for this time I am making an exception, fdupont@isc.org too) -- tel.718-260-4009 | web: http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director & Founder, OpenCA Labs Research Professor, NYU Poly Assistant Director, CRISSP http://crissp.poly.edu -- tel.718-260-4009 | web: http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director & Founder, OpenCA Labs Research Professor, NYU Poly Assistant Director, CRISSP http://crissp.poly.edu From pala@nyu.edu Fri Aug 3 10:44:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3030621F8E26 for ; Fri, 3 Aug 2012 10:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ng3vEZvKLGP for ; Fri, 3 Aug 2012 10:44:55 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E54BB21F8E23 for ; Fri, 3 Aug 2012 10:44:54 -0700 (PDT) Received: by qaea16 with SMTP id a16so2254089qae.10 for ; Fri, 03 Aug 2012 10:44:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=1zycKelG/kmxZSzjUklCmmZOVIsqI7kVdeFjUmqKxXk=; b=p44jvL076g4dtjM7JmuYXD6gtq3LyDB6Dr514H6Hvc01DqaKo2nSlXYDiwXiW1U3yv TbihzEbT2yqslyb8wOPtq26a1qklsymCGJANd95LnxQxdYJtCU0HkVBQqrmEkL8sssBS KNoq5n3S/5H/YOOUpSjDuTJmAHK5Te2dGUboWehyW2EBqW713EOTZJYMNT5ReDqqeuFb VVvhThKEulV5fs8WFGnh2MLhQVtd4JjiJ6yQDkRssvFNsFe4OCI4/nRO4x7XQSUxBOl5 DdVBXEG1T+4ay4+L9k3fU+RjFqMsjnAQ0dSE2yjg+Zw2DVwKQiiQmjjp06Dxn+Mvhzq9 5EIw== Received: by 10.229.136.137 with SMTP id r9mr1270537qct.80.1344015894384; Fri, 03 Aug 2012 10:44:54 -0700 (PDT) Received: from zeus.openca.dyndns.org (c-68-45-183-116.hsd1.nj.comcast.net. [68.45.183.116]) by mx.google.com with ESMTPS id cg7sm7830833qab.19.2012.08.03.10.44.53 (version=SSLv3 cipher=OTHER); Fri, 03 Aug 2012 10:44:53 -0700 (PDT) Message-ID: <501C0E0D.8020906@nyu.edu> Date: Fri, 03 Aug 2012 13:44:45 -0400 From: Massimiliano Pala User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: pkix@ietf.org References: <201208021732.q72HW5Jr070976@givry.fdupont.fr> In-Reply-To: <201208021732.q72HW5Jr070976@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl7I5k26MyKyiEdnTcwcT7U+H6VRUUK/PmK9lYr3dHqe008itgE4Z8E0aHDXaavYikLxjSb Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:44:56 -0000 Hello Francis, Thanks for the comments - as Scott wrote, it would be interesting if you could let us know what is, specifically, that you do not like and how this could be a problem for PKIs (why it should not be standardized). Our attempt is to provide another mechanism that CAs can use (if they want to) to distribute pre-computed OCSP responses - cheap, easy to deploy, and that would deliver (by using the DNS caching) the response close to the client (thus, enhancing their availability). Issue: - We need to improve the availability of OCSP responses. Today, the quality of service across different CAs is not enough for applications to enable strict revocation checking (issues: costs and connectivity issues (eg., latency)) The starting points for our proposal are: - We should try to provide an infrastructure for OCSP checking (rev info checking) that minimize unavailability of data because of network issues - Pre-computed OCSP responses can be provided via different access methods (e.g., HTTP, CDNs, FTP, etc.) - For high-volume websites, huge bandwidth is required on the OCSP side to provide services that meet the expectations (and high costs) of clients - Availability of OCSP responses could be increased by using widely deployed and distributed services like DNS / DNSSEC Given the problem, the well-defined boundaries, and the considerations on the need to address the availability of revocation information, we think that this I-D could provide a well-targeted mid-term solution to the issue. Any input on the matter that takes in consideration the above points, is more than welcome as the purpose here is to address a real issue that affects practically all the Internet users. Best, Max On 08/02/2012 01:32 PM, Francis Dupont wrote: > In your previous mail you wrote: > >> Time was short and I failed to get further feedback from the folks >> who "hated" (yes that was the exact phrase that was used) the idea >> as to WHY they do not support the idea. > => I attended another session so I didn't follow the presentation itself > but according to the slides in the meeting materials I am afraid I deeply > dislike the idea (i.e., haters++). BTW the DNS is in no way a "transport". > > Regards > > Francis.Dupont@fdupont.fr > (and for this time I am making an exception, fdupont@isc.org too) -- tel.718-260-4009 | web: http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director & Founder, OpenCA Labs Research Professor, NYU Poly Assistant Director, CRISSP http://crissp.poly.edu From ajs@anvilwalrusden.com Fri Aug 3 11:16:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBB721F8DE2 for ; Fri, 3 Aug 2012 11:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCHrrlD5sLg0 for ; Fri, 3 Aug 2012 11:16:48 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id E43D621F8E04 for ; Fri, 3 Aug 2012 11:16:47 -0700 (PDT) Received: from mail.yitter.info (dhcp-473a.meeting.ietf.org [130.129.71.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 223058A031 for ; Fri, 3 Aug 2012 18:16:46 +0000 (UTC) Date: Fri, 3 Aug 2012 14:16:44 -0400 From: Andrew Sullivan To: pkix@ietf.org Message-ID: <20120803181644.GB52922@mail.yitter.info> References: <501AAF29.9030307@DigiCert.com> <20120803034740.GA46906@crankycanuck.ca> <501B80B3.4000100@seantek.com> <501C0B15.4000700@isis.poly.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501C0B15.4000700@isis.poly.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:16:48 -0000 On Fri, Aug 03, 2012 at 01:32:05PM -0400, Massimiliano Pala wrote: > Also, since these responses go through DNS, it might solve the problem with > some environments (e.g., web-portals) where traffic toward OCSP servers > might be blocked - usually DNS lookups are enabled in that environment. I think you need to be a little more careful about your assumptions in this case. In my experience, large numbers of web portals permit DNS lookups _for some value of "permit"_. Many of them munge or otherwise mangle the DNS responses, and I have seen shipping DNS middleboxes that return an A response no matter what RRTYPE you looked up. The most egregious of these things are gradually getting ditched with the deployment of DNSSEC, but there's still a lot of garbage out there. This is especially true on public wifi networks, one of the places that good revokation checking is most urgently needed. This isn't an argument against the idea, just a note of caution about the operational realities of the network. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From stefan@aaa-sec.com Fri Aug 3 11:32:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5C511E8097 for ; Fri, 3 Aug 2012 11:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVK8puW2oh2k for ; Fri, 3 Aug 2012 11:32:55 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7A711E808D for ; Fri, 3 Aug 2012 11:32:54 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 49B0110FE312 for ; Fri, 3 Aug 2012 20:32:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MUTtKfmBm8ny for ; Fri, 3 Aug 2012 20:32:52 +0200 (CEST) Received: from s331.loopia.se (new-s34.loopia.se [194.9.94.94]) by s87.loopia.se (Postfix) with ESMTP id D151310FE0EE for ; Fri, 3 Aug 2012 20:32:52 +0200 (CEST) Received: (qmail 16791 invoked from network); 3 Aug 2012 18:32:52 -0000 Received: from unknown (HELO [10.39.8.210]) (stefan@fiddler.nu@[131.107.32.25]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 3 Aug 2012 18:32:52 -0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 03 Aug 2012 11:32:53 -0700 From: Stefan Santesson To: Simon Josefsson Message-ID: Thread-Topic: [pkix] OCSP 2560bis - responderID clarification In-Reply-To: <87pq78bbyh.fsf@latte.josefsson.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] OCSP 2560bis - responderID clarification X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:32:56 -0000 Thanks Simon. I'll include your updates. They seem fine with me. No I don't have an XML. I use the Awesome NroffEdit tool :) /Stefan On 12-08-03 1:45 AM, "Simon Josefsson" wrote: >Stefan Santesson writes: > >> Simon, >> >> I fully agree, >> The spec ought to say something about the expected information if the >>Name >> choice is chosen. >> >> The ASN.1 structure is defined, but some wording about content would be >> suitable. >> >> I can't see however that anything but the subject name of the OCSP >> responder (identical to the responder certificate) would go here. > >Thanks. How about adding something like this to section 4.2.2.3? > > The purpose of the ResponderID information is to allow clients to find > the certificate used to sign a signed OCSP response. Therefor, the > information MUST correspond to the certificate that was used to sign > the response. > >It should probably go early in the section, just after the first >bullet-point list. > >I am not confident that this is non-controverisal, as I'm not an OCSP >expert. I would appreciate if more people considered whether this text >makes sense or not. I am hoping that the paragraph is trivial to >everyone experienced with OCSP. > >When I wrote the OCSP support for GnuTLS I found this area to be >under-specified. If there is any deployment out there which puts >something other than the OCSP responder signer cert identity in the >ResponderID field, I would have expected guidance from the document on >what purpose the field serves. > >The introduction section also needs to be updated to describe this >change. I would propose adding something like: > > o Section 4.2.2.3 clarify that the ResponderID field corresponds to the > OCSP Responder signer certificate. > >Btw, I noticed a typo in the document: > >OLD: > o Section 4.1.1 specifies the ASN.1 syntax for the nonce >NEW: > o Section 4.4.1 specifies the ASN.1 syntax for the nonce > >If the XML is available in a respository somewhere, I could send you a >patch. :-) > >Cheers, >/Simon >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From i.grok@comcast.net Fri Aug 3 18:16:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A9A21F8DB4 for ; Fri, 3 Aug 2012 18:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+NnrYwWig4j for ; Fri, 3 Aug 2012 18:16:38 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF8521F8BFA for ; Fri, 3 Aug 2012 18:16:37 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id iRE41j0060EZKEL51RGfiy; Sat, 04 Aug 2012 01:16:39 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta01.westchester.pa.mail.comcast.net with comcast id iRGn1j00L2Ekl483MRGoKi; Sat, 04 Aug 2012 01:16:49 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id q741GYam025628 for ; Fri, 3 Aug 2012 21:16:34 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q741GYkT025627 for pkix@ietf.org; Fri, 3 Aug 2012 21:16:34 -0400 Date: Fri, 3 Aug 2012 21:16:34 -0400 From: Scott Schmit To: pkix@ietf.org Message-ID: <20120804011634.GA25458@odin.ulthar.us> Mail-Followup-To: pkix@ietf.org References: <501AB3A3.4020209@bbn.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <501AB3A3.4020209@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] reminder X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 01:16:38 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 02, 2012 at 01:06:43PM -0400, Stephen Kent wrote: > Below is the text that was briefed in the PKIX meeting yesterday and > that represents the current, proposed text for addition to Section > 3.2. Russ noted that we need to add a reference to the 2008 version of > X.509 from which we have cited text. Peter will reissue the doc with > this change. I plan to forward that version to the IESG a week after > it is posted, unless we hear otherwise. >=20 > Steve > ----- >=20 > Add the following paragraph to the end of RFC 5280, Section 3.2: >=20 > Consistent with Section 3.4.61 of X.509 (11/2008) we note that use > of self-issued certificates and self-signed certificates issued by > other than CAs are outside the scope of this specification. Thus, > for example, a web server or client might generate a self-signed > certificate to identify itself. These certificates, and how a > relying party uses them to authenticate asserted identities, are > both outside the scope of RFC 5280. As I read it, if you aren't a CA and generate a self-signed certificate, then that certificate isn't a PKIX certificate. Is that statement right? If so, it sort of screws up draft-ietf-dane-protocol: =46rom section 2.2.1: # 3 -- Certificate usage 3 is used to specify a certificate, or the # public key of such a certificate, that MUST match the end entity # certificate given by the server in TLS. This certificate usage is # sometimes referred to as "domain-issued certificate" because it # allows for a domain name administrator to issue certificates for a # domain without involving a third-party CA. The target certificate # MUST match the TLSA record. The difference between certificate # usage 1 and certificate usage 3 is that certificate usage 1 # requires that the certificate pass PKIX validation, but PKIX # validation is not tested for certificate usage 3. # # The certificate usages defined in this document explicitly only apply # to PKIX-formatted certificates in DER encoding [X.690]. If TLS # allows other formats later, or if extensions to this RRtype are made # that accept other formats for certificates, those certificates will # need their own certificate usage values. (TLSA Certificate usage 3 is intended for self-signed "PKIX" certificates.) Maybe the problem is that we talk about PKIX-formatted certificates vs. PKIX-validated certificates, but both are handled in RFC 5280. Can we distinguish the two? --=20 Scott Schmit --dDRMvlgZJXvWKvBx Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQBAYJKoZIhvcNAQcCoIIP9TCCD/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DTUwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBvkwggXhoAMCAQICAwR4CjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDcwNDEz NTc1MVoXDTEzMDcwNTA1MjcyNlowQDEbMBkGA1UEAwwSaS5ncm9rQGNvbWNhc3QubmV0MSEw HwYJKoZIhvcNAQkBFhJpLmdyb2tAY29tY2FzdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCxn+QJTgdUJ1RAOi6JbFsDfl21ZX/OPx/ttuXWQP1vWwBZybHU+4/+bRXH 5ONhjbc5ikZvz/E406iQLy2xMT5PI/hx4uIZQQYpkjxd4rCbbvLNACz5L+cFaGj4WfGwAXDv bw4nx8Mh3WjbR5yjBCWYqadiv7HWAWmhaJmuaTp/e+mO2EEOOdoNQ8b2mxMyN43TlElx6Zos t7g/eQUcLWgTB5apPhowCCGnFU6uHK053QsPmsmZ67gg8acpb5ic0+P+X1j+IgD3jcsDzjrF TPlrvU4ZuBYQJISqngbc2ua/uutx75Xs4iFXWNRlnYfZMFJy96USzrhIBRqcORrjbyGXAgMB AAGjggOtMIIDqTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFAxkdHPHW3mhf+gXJjezdazgoDRuMB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmkuZ3Jva0Bjb21jYXN0Lm5ldDCC AiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBT ZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9h aWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBACJi0f4m 0bSVq+pq4AHeC2Rj4S8rciW+Uce6LC69UlyVMijKv/pZNFM08vqRXEI9WpKQhKXacJ+rK9az DBmnxq1scqKhn7991V6Yt2t0tEY8vUX7q330GybUB/rQLNrh66GFXaEWU/S692pGzvUXeV+w zz48snMpoMHQdxkHHW5sQkpo99SF/vOA5/sqvFmJ+ai1iDRjtKcChjkmAtFmCKv/dNrXnvew 5+QnLlnE/TsW4Sdv3bcLdlthD4eavS3BdgXfX7dfj0ykel53J2Us3CikNbyuCsJpwMH+gX1j LcXZOYIDLzZXCFEOFajhgsAZ5JQrW0fFRxjGIp8Rs+rxdFwxggKXMIICkwIBATCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEeAowCQYFKw4DAhoFAKCB2DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA4MDQwMTE2MzRaMCMG CSqGSIb3DQEJBDEWBBRFVQ7vafb+vvWtGDIdE2YJF1grWjB5BgkqhkiG9w0BCQ8xbDBqMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASCAQAmqs41xbwdShG1SzqCbTdvjUVi6sD4fNnLUAHxr44kOLxpgRAqldbc ixuM4PABtmCB0jXfmBUXvZ2RVKO58FyTFChpL1hG46FMvacQQGpZNsQj3aZmb+dfT9hgdEb4 3sTgHBOovRlO8DKPCLs+7FRbywS5qtl6yxMLvElEDkcUS0PtB1sVuejMvD4EOdEyRpgjIZJP qb5K1QgU7tPYqV1Fvcre7GAB7ndYuvaayFoUEAuSqUE8z6OQV1KeRP8AWAXa7y1LfbnwP6t6 3oC0ItbeyOjOCIodncCC9PzT5IWEsQbYRVa/q8GPJBeMpCmaa3Y7lpwHrZzZ0WaA7ynDV5IT --dDRMvlgZJXvWKvBx-- From paul.hoffman@vpnc.org Sat Aug 4 08:41:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C024F21F87BE for ; Sat, 4 Aug 2012 08:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve+X6i3TxENd for ; Sat, 4 Aug 2012 08:41:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1640B21F86DC for ; Sat, 4 Aug 2012 08:41:41 -0700 (PDT) Received: from [192.168.0.22] (S01060026f3e16488.vc.shawcable.net [24.84.235.32]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q74EoPEc019118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 4 Aug 2012 07:50:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120804011634.GA25458@odin.ulthar.us> Date: Sat, 4 Aug 2012 08:41:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5170CB53-0BE5-404B-B60B-B6EAE221D8CC@vpnc.org> References: <501AB3A3.4020209@bbn.com> <20120804011634.GA25458@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1278) Cc: pkix@ietf.org Subject: Re: [pkix] reminder X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 15:41:41 -0000 On Aug 3, 2012, at 6:16 PM, Scott Schmit wrote: > On Thu, Aug 02, 2012 at 01:06:43PM -0400, Stephen Kent wrote: >> Below is the text that was briefed in the PKIX meeting yesterday and >> that represents the current, proposed text for addition to Section >> 3.2. Russ noted that we need to add a reference to the 2008 version = of >> X.509 from which we have cited text. Peter will reissue the doc with >> this change. I plan to forward that version to the IESG a week after >> it is posted, unless we hear otherwise. >>=20 >> Steve >> ----- >>=20 >> Add the following paragraph to the end of RFC 5280, Section 3.2: >>=20 >> Consistent with Section 3.4.61 of X.509 (11/2008) we note that use >> of self-issued certificates and self-signed certificates issued by >> other than CAs are outside the scope of this specification. Thus, >> for example, a web server or client might generate a self-signed >> certificate to identify itself. These certificates, and how a >> relying party uses them to authenticate asserted identities, are >> both outside the scope of RFC 5280. >=20 > As I read it, if you aren't a CA and generate a self-signed = certificate, > then that certificate isn't a PKIX certificate. Is that statement > right? Partially. Those certificates are outside the scope of PKIX. However... > If so, it sort of screws up draft-ietf-dane-protocol: >=20 > =46rom section 2.2.1: > # 3 -- Certificate usage 3 is used to specify a certificate, or = the > # public key of such a certificate, that MUST match the end entity > # certificate given by the server in TLS. This certificate usage = is > # sometimes referred to as "domain-issued certificate" because it > # allows for a domain name administrator to issue certificates for = a > # domain without involving a third-party CA. The target = certificate > # MUST match the TLSA record. The difference between certificate > # usage 1 and certificate usage 3 is that certificate usage 1 > # requires that the certificate pass PKIX validation, but PKIX > # validation is not tested for certificate usage 3. > # > # The certificate usages defined in this document explicitly only = apply > # to PKIX-formatted certificates in DER encoding [X.690]. If TLS > # allows other formats later, or if extensions to this RRtype are = made > # that accept other formats for certificates, those certificates will > # need their own certificate usage values. >=20 > (TLSA Certificate usage 3 is intended for self-signed "PKIX" > certificates.) No. It is intended for PKIX-formatted certificates, which is exactly = what the DANE spec says. > Maybe the problem is that we talk about PKIX-formatted certificates = vs. > PKIX-validated certificates, but both are handled in RFC 5280. Can you say why that's a problem? > Can we distinguish the two? Yes, easily. --Paul Hoffman From i.grok@comcast.net Sat Aug 4 18:02:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E903E21F87F8 for ; Sat, 4 Aug 2012 18:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYMwbeWWViMm for ; Sat, 4 Aug 2012 18:02:43 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id C65F621F87C4 for ; Sat, 4 Aug 2012 18:02:42 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id iosk1j0040EZKEL51p2laH; Sun, 05 Aug 2012 01:02:45 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta01.westchester.pa.mail.comcast.net with comcast id ip2s1j0092Ekl483Mp2ueR; Sun, 05 Aug 2012 01:02:54 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id q7512du6027938 for ; Sat, 4 Aug 2012 21:02:39 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q7512dcT027937 for pkix@ietf.org; Sat, 4 Aug 2012 21:02:39 -0400 Date: Sat, 4 Aug 2012 21:02:39 -0400 From: Scott Schmit To: pkix@ietf.org Message-ID: <20120805010239.GA25950@odin.ulthar.us> Mail-Followup-To: pkix@ietf.org References: <501AB3A3.4020209@bbn.com> <20120804011634.GA25458@odin.ulthar.us> <5170CB53-0BE5-404B-B60B-B6EAE221D8CC@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <5170CB53-0BE5-404B-B60B-B6EAE221D8CC@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] reminder X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 01:02:44 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 04, 2012 at 08:41:34AM -0700, Paul Hoffman wrote: > On Aug 3, 2012, at 6:16 PM, Scott Schmit wrote: > > On Thu, Aug 02, 2012 at 01:06:43PM -0400, Stephen Kent wrote: > >> Add the following paragraph to the end of RFC 5280, Section 3.2: > >>=20 > >> Consistent with Section 3.4.61 of X.509 (11/2008) we note that use > >> of self-issued certificates and self-signed certificates issued by > >> other than CAs are outside the scope of this specification. Thus, > >> for example, a web server or client might generate a self-signed > >> certificate to identify itself. These certificates, and how a > >> relying party uses them to authenticate asserted identities, are > >> both outside the scope of RFC 5280. > >=20 > > As I read it, if you aren't a CA and generate a self-signed certificate, > > then that certificate isn't a PKIX certificate. Is that statement > > right? >=20 > Partially. Those certificates are outside the scope of PKIX. However... >=20 > > If so, it sort of screws up draft-ietf-dane-protocol: > >=20 > > From section 2.2.1: > > # The certificate usages defined in this document explicitly only apply > > # to PKIX-formatted certificates in DER encoding [X.690]. If TLS > > # allows other formats later, or if extensions to this RRtype are made > > # that accept other formats for certificates, those certificates will > > # need their own certificate usage values. > >=20 > > (TLSA Certificate usage 3 is intended for self-signed "PKIX" > > certificates.) >=20 > No. It is intended for PKIX-formatted certificates, which is exactly > what the DANE spec says. >=20 > > Maybe the problem is that we talk about PKIX-formatted certificates vs. > > PKIX-validated certificates, but both are handled in RFC 5280. >=20 > Can you say why that's a problem? Because someone could easily use that paragraph to say, "there's no such thing as a PKIX-formatted certificate that isn't PKIX-validatable."=20 RFC 5280 =3D=3D PKIX, so being out of scope of RFC 5280 makes it not PKIX-anything. After all, how the certificate is signed determines if it's in scope of PKIX. > > Can we distinguish the two? >=20 > Yes, easily. I'd suggest we do that. I think think that's why people were trying to inject "use of" the certificates instead of "generation of" the certs-- to make that distinction. I'd be happier if the last sentence read: "Validation of these certificates, and how a relying party authenticates the asserted identities, are both outside the scope of RFC 5280." Then it makes sense for a certificate to be a PKIX[-formatted] certificate, but not PKIX-validatable. --=20 Scott Schmit --y0ulUmNC+osPPQO6 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQBAYJKoZIhvcNAQcCoIIP9TCCD/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DTUwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBvkwggXhoAMCAQICAwR4CjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDcwNDEz NTc1MVoXDTEzMDcwNTA1MjcyNlowQDEbMBkGA1UEAwwSaS5ncm9rQGNvbWNhc3QubmV0MSEw HwYJKoZIhvcNAQkBFhJpLmdyb2tAY29tY2FzdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCxn+QJTgdUJ1RAOi6JbFsDfl21ZX/OPx/ttuXWQP1vWwBZybHU+4/+bRXH 5ONhjbc5ikZvz/E406iQLy2xMT5PI/hx4uIZQQYpkjxd4rCbbvLNACz5L+cFaGj4WfGwAXDv bw4nx8Mh3WjbR5yjBCWYqadiv7HWAWmhaJmuaTp/e+mO2EEOOdoNQ8b2mxMyN43TlElx6Zos t7g/eQUcLWgTB5apPhowCCGnFU6uHK053QsPmsmZ67gg8acpb5ic0+P+X1j+IgD3jcsDzjrF TPlrvU4ZuBYQJISqngbc2ua/uutx75Xs4iFXWNRlnYfZMFJy96USzrhIBRqcORrjbyGXAgMB AAGjggOtMIIDqTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFAxkdHPHW3mhf+gXJjezdazgoDRuMB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmkuZ3Jva0Bjb21jYXN0Lm5ldDCC AiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBT ZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9h aWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBACJi0f4m 0bSVq+pq4AHeC2Rj4S8rciW+Uce6LC69UlyVMijKv/pZNFM08vqRXEI9WpKQhKXacJ+rK9az DBmnxq1scqKhn7991V6Yt2t0tEY8vUX7q330GybUB/rQLNrh66GFXaEWU/S692pGzvUXeV+w zz48snMpoMHQdxkHHW5sQkpo99SF/vOA5/sqvFmJ+ai1iDRjtKcChjkmAtFmCKv/dNrXnvew 5+QnLlnE/TsW4Sdv3bcLdlthD4eavS3BdgXfX7dfj0ykel53J2Us3CikNbyuCsJpwMH+gX1j LcXZOYIDLzZXCFEOFajhgsAZ5JQrW0fFRxjGIp8Rs+rxdFwxggKXMIICkwIBATCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEeAowCQYFKw4DAhoFAKCB2DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA4MDUwMTAyMzlaMCMG CSqGSIb3DQEJBDEWBBRS8ZeVBojNsvknDcTEpcS8yI4GmjB5BgkqhkiG9w0BCQ8xbDBqMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASCAQBM3WLHod55WVLm9v83CTS5gRLcv4uKF4/pBnxvvZJ03jPh9Z4dqjJf Sx5UJf+DE1WfP2uaLcirCK6RaVYJUlaZUcF9rXNSzKF6NJZ+//9J/FFv5viHkBCR3+E1xgM6 j9L59dgGpDZ0TthJDtQp5j+P5Z1H+mQ2U7tWiuzh+HJxtOY3n3uWPhniNNrIejK6POmgaJVG ++JuPWCd9KPK20UiY+kVJw+9QBu7sghwZc3FA0IiLGOG/d05ZZSXgPpe0axZGZth7sSN/lku MUeEQcw6NnTB8EA4/RB9Y+EhrtcIJMKSiM8sPtt90dNx64irDQKySI97af9fH9sY6L4L7niq --y0ulUmNC+osPPQO6-- From MBentkofsky@verisign.com Sun Aug 5 15:16:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E0C21F8552 for ; Sun, 5 Aug 2012 15:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 838zu9viMr4v for ; Sun, 5 Aug 2012 15:16:10 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 24E9C21F854A for ; Sun, 5 Aug 2012 15:16:08 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUB7wpUVLgmwObUdIWD/lGBsTt3drjszw@postini.com; Sun, 05 Aug 2012 15:16:09 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q75MG2kX028338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Aug 2012 18:16:02 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Sun, 5 Aug 2012 18:16:02 -0400 From: "Bentkofsky, Michael" To: Scott Rea , "pkix@ietf.org" , Massimiliano Pala Thread-Topic: [pkix] OCSP over DNS Thread-Index: AQHNcM7O8LkejacJgEabfjhX9QjuP5dLx6nw Date: Sun, 5 Aug 2012 22:16:01 +0000 Message-ID: <080FBD5B7A09F845842100A6DE7962330ADC24D4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <501AAF29.9030307@DigiCert.com> In-Reply-To: <501AAF29.9030307@DigiCert.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 22:16:10 -0000 Hi Scott and Massimiliano, As someone who has implemented a very large OCSP service for a well-known C= A and implemented parts of the software infrastructure very large DNS servi= ce operator, I think your proposal has general merit. I have reviewed the p= roposal although I am still thinking through some of the responses I've see= n so far and apparently have to catch-up on details such as RFC 4501. First, I would respond to the comments about overloading a DNS operation. I= n my experience, DNS is significantly lighter than a TCP-based OCSP and wou= ld take very considerably less computational (and likely network) resources= once implemented than an equivalent OCSP responder service. I've long thou= ght, since the initial inception of the "lightweight OCSP profile" in RFC 5= 019, that an even lighter way would be to use UDP. It has been my experienc= e that the TCP connection overhead is not only significant for increased cl= ient latency, but also significant in the computational resources of the se= rvers.=20 Besides the possibility of using UDP to reduce latency, I see the ability t= o use anycasting, quite typical in DNS service providers, to be a viable op= tion for distributing load. In earlier experiments, I have noticed that any= casting TCP services does not work well for some clients, most likely due t= o network misconfiguration. That data point is now a few years old. I do have a one question when I was reading through your proposal text. It = sounds like you are considering the DNS query as between the client directl= y to the CA's DNS service. Why not make use of the distributed nature of th= e DNS to make the request to a local resolver and possibly get the advantag= e of local caching? That is a more typical model for DNS (e.g. make a reque= st to a local resolver; local resolver makes recursive requests to authorit= ative servers). My only observation about this approach is that using a "dn= ssec" URI doesn't make sense since local resolvers will do the DNSSEC valid= ation, not the client. One potential downside I see is with the security guarantees. It is pretty = easy to forge UDP responses, and although the OCSP response is signed, one = could invent cases where "OCSP good" responses were replayed (when the cert= ificate had been revoked, but was still within the OCSP expiration window) = or worse: the unsigned "Unknown" response could be blasted much easier than= if the service were implemented over TCP. That all said, I'm on board in concept. Thanks, Michael -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Sco= tt Rea Sent: Thursday, August 02, 2012 12:48 PM To: pkix@ietf.org Subject: [pkix] OCSP over DNS G'day Folks, yesterday at PKIX we had some folks supporting the proposed OCSP over=20 DNS protocol (see:=20 https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/) and some=20 folks who said they did not like the idea. Time was short and I failed=20 to get further feedback from the folks who "hated" (yes that was the=20 exact phrase that was used) the idea as to WHY they do not support the=20 idea. Would those folks be willing to post their objections/justifications to=20 the list, and if are not quite ready to make a public declaration,=20 please send Max or I an email directly off-list as to reasons why you=20 would not support this proposal? Scott Rea or Massimiliano Pala Regards, --=20 Scott Rea _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From pritikin@cisco.com Sun Aug 5 20:41:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8731A21F84A6 for ; Sun, 5 Aug 2012 20:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCceIMF8nYbL for ; Sun, 5 Aug 2012 20:41:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AC84C21F84B3 for ; Sun, 5 Aug 2012 20:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=447; q=dns/txt; s=iport; t=1344224487; x=1345434087; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oWc0/c1PAfOLWWwMFlBkZFScGetaoj/H/+mLadjucSk=; b=jl22O2qJe34pQAkz1XKfG4mWhnhXRjNBF/zb6D9fV/gvKuiUmtu24nzX 1NgzU/1a4JrnRfJYuTZ4pCpKPzvQIY8ZGUAjvp6xULsGaTDUWn5GwfQy2 i/DcxN3CWPBX50Hg4MTgEf/IPJbbV+xiI9gv7uxdWJpxlC2bge0x2MEjz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwFAGg8H1CtJV2d/2dsb2JhbABFhTS0B4EHgiABAQECAQEBAQEPASc0CwULAgEINhAnCyUCBA4FCRmHZQYLmzefDYtKhiRgA5VJjiaBZoJf X-IronPort-AV: E=Sophos;i="4.77,717,1336348800"; d="scan'208";a="108660097" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 06 Aug 2012 03:41:27 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q763fR5w000827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Aug 2012 03:41:27 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.155]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Sun, 5 Aug 2012 22:41:26 -0500 From: "Max Pritikin (pritikin)" To: Stephen Kent Thread-Topic: [pkix] minutes posted Thread-Index: AQHNcM3wQc18wVhNKkeFOepQkcGKRZdMfPUA Date: Mon, 6 Aug 2012 03:41:26 +0000 Message-ID: References: <501AAE27.4030305@bbn.com> In-Reply-To: <501AAE27.4030305@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.0.163] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19084.006 x-tm-as-result: No--30.916900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <01E162A4BAF69940BEB5D52392C32A16@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] minutes posted X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 03:41:28 -0000 Thanks. Looks good to me.=20 For ease of pkix readers the URL is: http://www.ietf.org/proceedings/84/minutes/minutes-84-pkix.pdf - max On Aug 2, 2012, at 9:43 AM, Stephen Kent wrote: > Please contact me with comments and corrections, over the next 10-12 days= . >=20 > Thanks, >=20 > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Mon Aug 6 05:35:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE0321F85F7 for ; Mon, 6 Aug 2012 05:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 304FKwmGg1VE for ; Mon, 6 Aug 2012 05:35:27 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED0B21F848B for ; Mon, 6 Aug 2012 05:35:26 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id EC0E2128064; Mon, 6 Aug 2012 14:35:25 +0200 (CEST) In-Reply-To: <50156F44.6010305@bbn.com> References: <50156F44.6010305@bbn.com> To: Stephen Kent MIME-Version: 1.0 X-KeepSent: DD960A2C:B64C13FE-C1257A52:003D2B54; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Mon, 6 Aug 2012 14:35:18 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 06/08/2012 14:35:26, Serialize complete at 06/08/2012 14:35:26 Content-Type: multipart/alternative; boundary="=_alternative 004525CBC1257A52_=" Cc: pkix Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 12:35:28 -0000 Message en plusieurs parties au format MIME --=_alternative 004525CBC1257A52_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Steve, I vote for D; i.e. : D - the respondent volunteers to work on a new version of 2560bis. I hope to be able to deliver such a new version within two weeks from now. I plan to add explanations: - for OCSP clients when they build a request, - for OCSP clients when they verify a response. As an example, explanations are missing to explain how to process the=20 responderID field from a ResponseData. I plan to add requirements related to key rollover : 1 - CA key rollover (without delegated OCSP responder), 2 - delegated OCSP responders: - OCSP key rollover (without CA key rollover), - CA key rollover without a new OCSP key, and - CA key rollover with a new OCSP key. I plan to work from version -05 which is not "good enough", but=20 much better than version -04 with all its annexes. Denis De : Stephen Kent A : pkix Date : 29/07/2012 19:13 Objet : [pkix] 2560bis Envoy=E9 par : pkix-bounces@ietf.org Folks, Recent messages exchanges point to significant disagreement about the=20 future direction for this doc. At the March meeting Stefan presented a proposal for how=20 to move ahead, as outlined in his slides. As noted in the minutes, the audience=20 (at the mic) included one indication of support for this streamlined approach, and=20 one expression of concern. Not a lot of interest. Work on this doc has dragged on for 2 years now. In October of 2011=20 Santosh argued that version -04 of the doc was, in his opinion, a step backwards, adding=20 more confusion to RFC 2560 vs. clarifying it. Stefan agreed (in a message in March of=20 2012), and thus he created the current, stripped-down version of the doc (-05)=20 which was published recently. Given the mixed response to this version, it's not clear that the WG=20 members who are interested in OCSP clarifications are in agreement on how to proceed. So, let's begin a straw poll on the topic. Here are the options I am=20 offering: A - continue to work with the -05 version as the basis for an RFC B - revert to the -04 version as the basis for an RFC C - don't publish a clarifications document for OCSP D - the respondent volunteers to work on a new version of 2560bis Please send your replies to the list starting now. The straw poll will=20 close in two weeks, on August 12. While there are many other, legitimate=20 comments one could offer, I am interested only in replies to this multiple choice straw=20 poll (i.e., no essay replies :-) ) Thanks, Steve =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 004525CBC1257A52_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Steve,

I vote for D; i.e. :

D - the respondent volunteers to work on a new version of 2560bis.

I hope to be able to deliver such a new v= ersion within two weeks from now.

I plan to add explanations:
   - for OCSP clients when they build a request,
   - for OCSP clients when they verify a response.

As an example, explanations are missing to explain how to process the responderID field from a ResponseData.

I plan to add requirements related to key rollover :
    1 - CA key rollover (without delegated OCSP responder),
    2 - delegated OCSP responde= rs:
          - OCSP key rollover (without CA key rollover),
          - CA k= ey rollover without a new OCSP key, and
          - CA k= ey rollover with a new OCSP key.

I plan to work from version -05 which is not "good enough", but
much better than version -04 with all its annexes.

Denis



De :     &= nbsp;  Stephen Kent <kent@bbn.c= om>
A :     &n= bsp;  pkix <pkix@ietf.org><= /font>
Date :    =    29/07/2012 19:13
Objet :        [pkix] 2560bis
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



Folks,

Recent messages exchanges point to significant disagreement about the
future direction
for this doc. At the March meeting Stefan presented a proposal for how
to move
ahead, as outlined in his slides. As noted in the minutes, the audience
(at the mic)
included one indication of support for this streamlined approach, and
one expression
of concern. Not a lot of interest.

Work on this doc has dragged on for 2 years now. In October of 2011
Santosh argued that
version -04 of the doc was, in his opinion, a step backwards, adding
more confusion to
RFC 2560 vs. clarifying it. Stefan agreed (in a message in March of
2012), and
thus he created the current, stripped-down version of the doc (-05)
which was published
recently.

Given the mixed response to this version, it's not clear that the WG
members who are interested
in OCSP clarifications are in agreement on how to proceed.

So, let's begin a straw poll on the topic.  Here are the options I am
offering:

    A - continue to work with the -05 version as the basis for an RFC
    B - revert to the -04 version as the basis for an RFC
    C - don't publish a clarifications document for OCSP
    D - the respondent volunteers to work on a new version of 2560bis

Please send your replies to the list starting now. The straw poll will close
in two weeks, on August 12. While there are many other, legitimate
comments one could
offer, I am interested only in replies to this multiple choice straw
poll (i.e., no
essay replies :-) )

Thanks,

Steve


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 004525CBC1257A52_=-- From denis.pinkas@bull.net Mon Aug 6 05:37:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B858F21F86B0 for ; Mon, 6 Aug 2012 05:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9Anm5cyUJMB for ; Mon, 6 Aug 2012 05:37:30 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 81BF721F86AB for ; Mon, 6 Aug 2012 05:37:29 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id E963A12805F; Mon, 6 Aug 2012 14:37:28 +0200 (CEST) In-Reply-To: <20120801212009.D99891A10B@ld9781.wdf.sap.corp> References: <50193573.1090303@nist.gov> <20120801212009.D99891A10B@ld9781.wdf.sap.corp> To: mrex@sap.com MIME-Version: 1.0 X-KeepSent: 3E872E2B:E27194EE-C1257A52:003A81A2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Mon, 6 Aug 2012 14:37:21 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 06/08/2012 14:37:29, Serialize complete at 06/08/2012 14:37:29 Content-Type: multipart/alternative; boundary="=_alternative 0045511AC1257A52_=" Cc: pkix Subject: Re: [pkix] 2560bis (essay version) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 12:37:31 -0000 Message en plusieurs parties au format MIME --=_alternative 0045511AC1257A52_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Martin, I agree with you that only two cases (besides a local configuration which=20 is OPTIONAL) SHALL be supported. However, I would rephrase it slightly differently: The key that is able to verify a SingleResponse (within a=20 BasicOCSPResponse) MUST be : (1) either the certificate signer key, (2) or the key from an OCSP responder signed by the certificate signer=20 key, and in this case the OCSP responder cert MUST be included in the OCSP=20 response.=20 Denis De : mrex@sap.com (Martin Rex) A : "David A. Cooper" Cc : pkix Date : 01/08/2012 23:20 Objet : Re: [pkix] 2560bis (essay version) Envoy=E9 par : pkix-bounces@ietf.org David A. Cooper wrote: >=20 > Please read=20 > http://www.ietf.org/mail-archive/web/pkix/current/msg27687.html for an=20 > example of the confusion that the text in RFC 2560 is causing. This is=20 > not about making changes to the protocol and then trying to achieve=20 > greater adoption of those changes, it is about making the document=20 > sufficiently clear and unambiguous that problems like the one described=20 > in that message can be avoided in the future. I haven't fully read through this, but it appears to be quite related to my complaint about Appendix E of the -04 document to be lacking requirements on inclusion of which particular certs in the OCSP response in order to provide a basis for interop. Without such requirements about which certs must be present in the OCSP response, interop will remain a lucky coincidence rather than a result of conscious design decisions. And as an implementor, I would limit my OCSP to exactly two cases: (1) certificate signer key also signed the OCSP response (2) certificate signer key also signed an OCSP responder cert, and this OCSP responder cert MUST be included in the OCSP response.=20 >=20 > In this message, you are again asking for changes to be made. For=20 > example you said: > > What seems to be badly lacking in Appendix E of -04 is the=20 requirements > > of which certs MUST be included in the OCSP response for each of the > > example CA/OCSP architecture/hierarchy, except for Figure 1 (where > > no cert is necessary). >=20 > I was given a very strict mandate to not make any changes to OCSP. Can=20 > you show me where this "MUST" requirement appears in RFC 2560? If not,=20 > then how could I include such a "MUST" requirement in 2560bis without=20 > breaking my promise not to make any changes to the protocol. This=20 > proposed change may be a good idea, but that doesn't mean it's not a=20 change. First, the rest of my reply was under the stated premise: =3D =3D This sounds like you're asking for =5Fchanging=5F the existing protocol =3D by publishing a new spec with different or additional requirements. and secondly, I'm against requiring OCSP clients to support fancy PKI models. However the complete lack of details what needs to be included in an OCSP response in order to provide a basis for interop is a DEFECT of rfc2560.=20 I would be perfectly OK with augmenting the existing spec with something like "In order to provide reliable interoperability on this protocol options, the following additional requirements are necessary, that are not part of rfc2560 (but might have been obvious implications for some implementors anyhow". If you approach rfc2560 from the viewpoint of formal correctness proofing, you will immediately notice which protocol options are underspecified and where you will encounter interop problems with implementers who do not read a spec and create an implementation with any kind of formal correctness in mind (i.e. planned and predictable behaviour in unknown future usage scenarios). >=20 > You also say that "There really ought to be a requirement that=20 > implementations (of CA and OCSP software) MUST support short-lived OCSP=20 > signer certs...." Again, that may be a good idea, but can you find that = > requirement in RFC 2560? If not, then wouldn't including such a=20 > requirement in 2560bis be a change? Same as above. >=20 > The final paragraph in your message proposes reordering the checks in=20 > Section 2.3.6. However, the checks in Section 2.3.6 are listed in the=20 > same order as they appear in Section 3.2 of RFC 2560. While one could=20 > certainly reorder them without changing the protocol since the text does = > not specify that the checks need to be performed in the order they are=20 > listed, it would seem that reordering them would be inconsistent with=20 > the approach that you are advocating of "doing minimal changes to the=20 > original document." rfcdiff visualizes this as newly added text: http://tools.ietf.org/rfcdiff?url1=3Drfc2560.txt&url2=3Ddraft-ietf-pkix-rfc= 2560bis-04.txt ...which is one of the reasons that I'm violently opposed to completely rearrange the document structure in the fasion of -04 Concerning the same info in section of rfc2560 section 3.2 a clarifying text that the ordering in the enumeration is not normative, and it might be sensible to perform the public key signature verification at the end, rather than as 2nd check, because it is likely the most "expensive" operation and one should avoid making public key crypto operations with public keys before it has been established that these keys are trustworthy. >=20 > You also misrepresent RFC 5280 in your message. RFC 5280 very clearly=20 > allows CAs to sign CRLs with a different key than was used to sign the=20 > certificates covered by the CRL, and notes that it may be necessary for=20 > a relying party to build a separate certification path for the=20 > certificate needed to verify the signature on the CRL. Quoting from rfc5280, section 5.1.1.3 http://tools.ietf.org/html/rfc5280#section-5.1.1.3 The use of separate CA certificates for validation of certificate signatures and CRL signatures can offer improved security characteristics; however, it imposes a burden on applications, and it might limit interoperability. Many applications construct a certification path, and then validate the certification path (Section 6). CRL checking in turn requires a separate certification path to be constructed and validated for the CA's CRL *> signature validation certificate. Applications that perform CRL *> checking MUST support certification path validation when certificates *> and CRLs are digitally signed with the same CA private key. These applications SHOULD support certification path validation when certificates and CRLs are digitally signed with different CA private keys. rfc5280 is pretty explicit that support for CRLs that are not signed by the same CA key that signed the certificate is OPTIONAL, because MINIMUM REQUIREMENT RPs will likely not support it. Keep in mind that CRLs, in contrast to OCSP, lack a standardized carry-on container for CRL signer certificates. Keep also in mind, that construction(!) of a certificate path is explicitly outside of the scope of rfc5280. Which more-or-less means that all options described in rfc5280 that require certificate path construction are implicitly outside the scope of rfc5280 as well (and very likely missing in minimum requirement RPs): http://tools.ietf.org/html/rfc5280#page-73 The primary goal of path validation is to verify the binding between a subject distinguished name or a subject alternative name and subject public key, as represented in the target certificate, based on the public key of the trust anchor. In most cases, the target certificate will be an end entity certificate, but the target certificate may be a CA certificate as long as the subject public key is to be used for a purpose other than verifying the signature on a public key certificate. Verifying the binding between the name and subject public key requires obtaining a sequence of certificates that *> support that binding. The procedure performed to obtain this *> sequence of certificates is outside the scope of this specification. > > As for OCSP, contrary to your assertion, relying parties are *NOT* > required to be able to validate responses if the response > (or the responder's certificate) was signed with a different key > than the target certificate. That is a misunderstanding. I'm perfectly aware and OK with this. > > I cannot find a single statement in RFC 2560 that states=20 > that conforming applications MUST be able to validate such responses,=20 > and so there is no such statement in 2560bis either. What is lacking in RFC2560, and should be added in rfc2560bis is that when using a different OCSP signer cert, then the OCSP server MUST include all certs that will be necessary for processing this OCSP response *within* the OCSP response. In general, this also means that the examples in Figure 7, Figure 8 and Figure 9 of -04 are incorrect, because in general a cross-cert between the cert-signing CA cert and the OCSP-responder signing CA cert will be necessary, unless the OCSP request contains an unambiguous proof that the OCSP client is in posession of the rootCA cert from Figures 7, 8, 9 -Martin =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 0045511AC1257A52_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Martin,

I agree with you that only two cases (bes= ides a local configuration which is OPTIONAL) SHALL be supported.
However, I would rephrase it slightly dif= ferently:

The key that is able to verify a SingleRe= sponse (within a BasicOCSPResponse) MUST be :
(1) either the certificate signer key,
(2) or the key from an OCSP responder signed by the certificate signer key,
   and in this case the OCSP responder cert MUST be included in the OCSP response.

Denis




De :     &= nbsp;  mrex@sap.com (Martin Rex)
A :     &n= bsp;  "David A. Cooper" <david.cooper@nist.gov>
Cc :   &nb= sp;    pkix <pkix@ietf.o= rg>
Date :    =    01/08/2012 23:20
Objet :        Re: [pkix] 2560bis (essay version)
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



David A. Cooper wrote:
>
> Please read
> http://www.ietf.org/mail-archive/web/p= kix/current/msg27687.html for an
> example of the confusion that the text in RFC 2560 is causing.  T= his is
> not about making changes to the protocol and then trying to achieve
> greater adoption of those changes, it is about making the document
> sufficiently clear and unambiguous that problems like the one described
> in that message can be avoided in the future.

I haven't fully read through this, but it appears to be quite related
to my complaint about Appendix E of the -04 document to be lacking
requirements on inclusion of which particular certs in the OCSP response
in order to provide a basis for interop.  Without such requirements
about which certs must be present in the OCSP response, interop will
remain a lucky coincidence rather than a result of conscious design
decisions.

And as an implementor, I would limit my OCSP to exactly two cases:
(1) certificate signer key also signed the OCSP response
(2) certificate signer key also signed an OCSP responder cert,
   and this OCSP responder cert MUST be included in the OCSP response.


>
> In this message, you are again asking for changes to be made.  For
> example you said:
> > What seems to be badly lacking in Appendix E of -04 is the requir= ements
> > of which certs MUST be included in the OCSP response for each of the
> > example CA/OCSP architecture/hierarchy, except for Figure 1 (wher= e
> > no cert is necessary).
>
> I was given a very strict mandate to not make any changes to OCSP.  Can
> you show me where this "MUST" requirement appears in RFC 2560?  If not,
> then how could I include such a "MUST" requirement in 2560bis without
> breaking my promise not to make any changes to the protocol.  This
> proposed change may be a good idea, but that doesn't mean it's not a change.


First, the rest of my reply was under the stated premise:

=3D
=3D This sounds like you're asking for =5Fchanging=5F the existing protocol=
=3D by publishing a new spec with different or additional requirements.


and secondly, I'm against requiring OCSP clients to support fancy PKI
models.  However the complete lack of details what needs to be include= d
in an OCSP response in order to provide a basis for interop is a
DEFECT of rfc2560.

I would be perfectly OK with augmenting the existing spec with
something like

"In order to provide reliable interoperability on
this protocol options, the following additional requirements are
necessary, that are not part of rfc2560 (but might have been
obvious implications for some implementors anyhow".

If you approach rfc2560 from the viewpoint of formal correctness proofing,<= br> you will immediately notice which protocol options are underspecified
and where you will encounter interop problems with implementers who
do not read a spec and create an implementation with any kind of formal
correctness in mind (i.e. planned and predictable behaviour
in unknown future usage scenarios).


>
> You also say that "There really ought to be a requirement that
> implementations (of CA and OCSP software) MUST support short-lived OCSP
> signer certs...."  Again, that may be a good idea, but can you find that
> requirement in RFC 2560?  If not, then wouldn't including such a
> requirement in 2560bis be a change?

Same as above.


>
> The final paragraph in your message proposes reordering the checks in
> Section 2.3.6.  However, the checks in Section 2.3.6 are listed in the
> same order as they appear in Section 3.2 of RFC 2560. While one could
> certainly reorder them without changing the protocol since the text does
> not specify that the checks need to be performed in the order they are
> listed, it would seem that reordering them would be inconsistent with
> the approach that you are advocating of "doing minimal changes to the
> original document."

rfcdiff visualizes this as newly added text:

http://tools.= ietf.org/rfcdiff?url1=3Drfc2560.txt&url2=3Ddraft-ietf-pkix-rfc2560bis-0= 4.txt

...which is one of the reasons that I'm violently opposed to
completely rearrange the document structure in the fasion of -04


Concerning the same info in section of rfc2560 section 3.2
a clarifying text that the ordering in the enumeration is not normative,
and it might be sensible to perform the public key signature verification at the end, rather than as 2nd check, because it is likely the most
"expensive" operation and one should avoid making public key crypto
operations with public keys before it has been established that these
keys are trustworthy.


>
> You also misrepresent RFC 5280 in your message.  RFC 5280 very clearly
> allows CAs to sign CRLs with a different key than was used to sign the
> certificates covered by the CRL, and notes that it may be necessary for
> a relying party to build a separate certification path for the
> certificate needed to verify the signature on the CRL.


Quoting from rfc5280, section 5.1.1.3

  http://tools.ietf.org/html/rfc5280#section-5.1.1= .3

                    The use of separate CA certificates for validation
  of certificate signatures and CRL signatures can offer improved
  security characteristics; however, it imposes a burden on
  applications, and it might limit interoperability.  Many appli= cations
  construct a certification path, and then validate the certification=
  path (Section 6).  CRL checking in turn requires a separate
  certification path to be constructed and validated for the CA's CRL
*> signature validation certificate.  Applications that perform CRL
*> checking MUST support certification path validation when certificates=
*> and CRLs are digitally signed with the same CA private key.  The= se
  applications SHOULD support certification path validation when
  certificates and CRLs are digitally signed with different CA privat= e
  keys.


rfc5280 is pretty explicit that support for CRLs that are not signed
by the same CA key that signed the certificate is OPTIONAL, because
MINIMUM REQUIREMENT RPs will likely not support it.

Keep in mind that CRLs, in contrast to OCSP, lack a standardized
carry-on container for CRL signer certificates.


Keep also in mind, that construction(!) of a certificate path is
explicitly outside of the scope of rfc5280.  Which more-or-less
means that all options described in rfc5280 that require certificate
path construction are implicitly outside the scope of rfc5280 as well
(and very likely missing in minimum requirement RPs):

  = http://tools.ietf.org/html/rfc5280#page-73

  The primary goal of path validation is to verify the binding betwee= n
  a subject distinguished name or a subject alternative name and
  subject public key, as represented in the target certificate, based=
  on the public key of the trust anchor.  In most cases, the target
  certificate will be an end entity certificate, but the target
  certificate may be a CA certificate as long as the subject public key
  is to be used for a purpose other than verifying the signature on a
  public key certificate.  Verifying the binding between the name and
  subject public key requires obtaining a sequence of certificates that
*> support that binding.  The procedure performed to obtain this
*> sequence of certificates is outside the scope of this specification.<= br>

>
> As for OCSP, contrary to your assertion, relying parties are *NOT*
> required to be able to validate responses if the response
> (or the responder's certificate) was signed with a different key
> than the target certificate.

That is a misunderstanding.  I'm perfectly aware and OK with this.


>
> I cannot find a single statement in RFC 2560 that states
> that conforming applications MUST be able to validate such responses,
> and so there is no such statement in 2560bis either.

What is lacking in RFC2560, and should be added in rfc2560bis is
that when using a different OCSP signer cert, then the OCSP server
MUST include all certs that will be necessary for processing this
OCSP response *within* the OCSP response.

In general, this also means that the examples in
Figure 7, Figure 8 and Figure 9 of -04 are incorrect, because
in general a cross-cert between the cert-signing CA cert and the
OCSP-responder signing CA cert will be necessary, unless the
OCSP request contains an unambiguous proof that the OCSP client
is in posession of the rootCA cert from Figures 7, 8, 9



-Martin
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 0045511AC1257A52_=-- From jeremy.rowley@digicert.com Mon Aug 6 12:05:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8713921F844C for ; Mon, 6 Aug 2012 12:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWFTZQdIGqRl for ; Mon, 6 Aug 2012 12:05:02 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id EB48421F8499 for ; Mon, 6 Aug 2012 12:05:01 -0700 (PDT) Received: from JROWLEYL1 (unknown [64.78.193.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 51DD48FA0A4 for ; Mon, 6 Aug 2012 13:05:01 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1344279901; bh=u+4U0dwV5//XnawlsrnszmWp4Hy2I+Tqaqp04nEZd1U=; h=Reply-To:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=upOl0KsqHSHi1K4jUCUfpY8RsMQTc1vAOPEHM4ROJZhPdhnqr7wlXHSdRq06fcACM byYbphAsjj6uHu1/BZO355DNTalY4vfHyKI9uNZ34hzLcwCKf5hhym/MTocVltdVqG rwTtl1Ju6wtcyqxRpNGBdnY2D1EtKK8EPbkclXfA= From: "Jeremy Rowley" To: Date: Mon, 6 Aug 2012 13:05:04 -0600 Organization: DigiCert Message-ID: <1b2401cd7406$633cb0c0$29b61240$@digicert.com> X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac10Bl7KfqA+OnfST/yyst/GTeiX9A== Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_1B1C_01CD73D4.1874A110" Subject: [pkix] Concerns with draft-ietf-pkix-caa-10 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jeremy.rowley@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:05:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1B1C_01CD73D4.1874A110 Content-Type: multipart/alternative; boundary="----=_NextPart_001_1B1D_01CD73D4.1874A110" ------=_NextPart_001_1B1D_01CD73D4.1874A110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everyone, Because there are a variety of instances where a DNS record might not accurately reflect the appropriate issuing CA (such as improper updating, a delay in display, etc.) and compliance with this RFC is entirely voluntary by the CA community, the requirements in Section 3 should be changed from "MUST" to "SHOULD" recommendations. Changing this section would allow implementing CAs to accommodate customers who do not have a streamlined DNS record updating system and make implementation more practical. I also think the section on using DNSSEC to authenticate CAA RRs needs further development. The recommendation to use DNSSEC in connection with the proposal would be strengthened significantly if the proposal required the DNS record holder to maintain and make available an archive of DNS records instead of issuing CAs. My biggest concern would be addressing the potential abuse mentioned in Section 5.5. Many enterprises have separate roles or departments that handle DNS records from those ordering digital certificates. In fact, these roles are often not in the same country. This creates a probable point of failure by the implementers. This separation between certificate requesters and DNS record controllers also increases the risk that the criticality flag can be abused as the controllers may be unaware of the variety of certificates uses within the enterprises. A bad-acting CA could lock the enterprise into a long term and exclusive agreement without the enterprise fully realizing the practical impact of agreement. The document should address the issue further and provide a recommendation on how to overcome this likely scenario. Jeremy ------=_NextPart_001_1B1D_01CD73D4.1874A110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = everyone,

 

Because there are a variety of instances where a DNS = record might not accurately reflect the appropriate issuing CA (such as = improper updating, a delay in display, etc.) and compliance with this = RFC is entirely voluntary by the CA community, the requirements in = Section 3 should be changed from “MUST” to = “SHOULD” recommendations.  Changing this section would = allow implementing CAs to accommodate customers who do not have a = streamlined DNS record updating system and make implementation more = practical.

 

I also think the section on using DNSSEC to = authenticate CAA RRs needs further development. The recommendation to = use DNSSEC in connection with the proposal would be strengthened = significantly if the proposal required the DNS record holder to maintain = and make available an archive of DNS records instead of issuing = CAs.

 

My biggest concern would be addressing the = potential abuse mentioned in Section 5.5.  Many enterprises have = separate roles or departments that handle DNS records from those = ordering digital certificates. In fact, these roles are often not in the = same country.  This creates a

probable point of failure by the = implementers.  This separation between certificate requesters and = DNS record controllers also increases the risk that the criticality flag = can be abused as the controllers may be unaware of the variety of = certificates uses within the enterprises.  A bad-acting CA could = lock the enterprise into a long term and exclusive agreement without the = enterprise fully realizing the practical impact of agreement.  The = document should address the issue further and provide a recommendation = on how to overcome this likely scenario.

 

Jeremy

 

------=_NextPart_001_1B1D_01CD73D4.1874A110-- ------=_NextPart_000_1B1C_01CD73D4.1874A110 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRJTCCA7cw ggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAw MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShY YAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g 1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ 1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwID AQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SS y4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTT PYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuy CSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3 bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVt bI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIwggagMIIFiKADAgECAhAFm5+/ MkIB9r7DDB+mmmhdMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMTAeFw0xMjA3MjAwMDAwMDBaFw0xNTEwMTgxMjAwMDBaMEkxCzAJBgNVBAYT AlVTMQ8wDQYDVQQHEwZMaW5kb24xETAPBgNVBAoTCERpZ2lDZXJ0MRYwFAYDVQQDEw1KZXJlbXkg Um93bGV5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArLme1zPa9DOoLcEvVa4LbF/k fBoGOfiJ0E371aJ6R2jLNu3kB8lqN1DvXY0M42dZKswFLXcKbLxYyAfYpCq8vp9uu5cWPSV/QZ87 e3YRPALKO9KK1Fs7OnMRf9L0gVFORp7veqGfaPqlchAt91pGBKcEHKkqsP/4uz8u3ezmh5g/nSAo dsyoRWEhJnxLYw6d8InufexYv3ozO4k1Yn46n7NEyJ3+u/fUcUArNFN/nqfsaCDjx2oKimwDYTTU CK6jRdGZnA7KQeWjq/o4RVyDNMfrxQF+JUGeXwMKg+/WzeSTLXDddRxTVz69AXtZuapbKrAyuOH4 lE3oTKlZTjAxNwIDAQABo4IDaTCCA2UwHwYDVR0jBBgwFoAUFQASKxOYspkH7R7for5XDStnAs0w HQYDVR0OBBYEFOOgPw3RnP3nIz5OEuzi1UzUWCHVMCUGA1UdEQQeMByBGmplcmVteS5yb3dsZXlA ZGlnaWNlcnQuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNz dXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6Bggr BgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABh AG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEA bgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAA YQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBl AGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEA Rf1rMMc+ToXbQjEgfeD9wgW5zc6rA+2TF5gx6R0472aSc64wSpgNFEWpAZ42Z/dsWZRl89OJ3juF BHHUqWDTZRz170r8pcCwNKc04behmrHTRek6UgK6+Bq1n5RPNJL8etvaSyf5KFu5UrAEGgP40m2a v4NcFBmawTCAJW4XGHalFVZOUMC5Kuo+wZlp8rYpYATuO4Dl//nB295hLil8eQR/xHGvwEnn3SOO pN3jzw5JMgjgGqKbojtsAaoxzLgXkxKBsLGrbITSp52EiMZN3kD/NWBEokqL4p5Vm+UAX/K/QTLa r89nA1TejDmSQH1yfsDWe7IAAFLEBNlHv3ZbOjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUA UOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZ MBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMxFTAT BgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMY RGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqv y15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LN b3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26C cz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djP Hgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGG MDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEF BQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5o dHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkA YwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABv AGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgA ZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABp AGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkA bgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBu AGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQuY29t L0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRo dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2 hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0G A1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd 823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yx XUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwz BjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4 PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP6 1+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCA74w ggO6AgEBMHYwYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAFm5+/ MkIB9r7DDB+mmmhdMAkGBSsOAwIaBQCgggIdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMDgwNjE5MDUwNFowIwYJKoZIhvcNAQkEMRYEFFaTKKZFGbwfgZqW/Uke +dHzy0CYMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3Vy ZWQgSUQgQ0EtMQIQBZufvzJCAfa+wwwfpppoXTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNV BAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQBZufvzJCAfa+wwwfpppoXTCBqwYJ KoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJ YIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG 9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAN BgkqhkiG9w0BAQEFAASCAQCWURmzneZ/Ulb2g//x+PCei1KsoDda4U9nSeM3jT+51DTSC+WocE1U i6tyV5wCm/1hUMdcOerhlAIg2v+pVWAOYKqNTZqLLBrT9rYjcEtkBA3stCfak//QP/rdCpNUWUDB VTHHdaTqmes8L38uda+vPWoXUOT/VTSvKHDx2trH+afO50xzl/k7ez1NI9UiWla0y9YPtQy2+Dhv 5hhjul+f/BowmYH8j0P9ui8x4dods//84YcKvtLIFPdI3cAW3McsuHMEgicaUjItVfVuhLzQEY7s 8EgJG4brKnhyw6mU/6u3YQLbdMOGPks3locy7oF0Y18g/waNuI7l35SA/g/6AAAAAAAA ------=_NextPart_000_1B1C_01CD73D4.1874A110-- From ajs@anvilwalrusden.com Mon Aug 6 12:26:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FF111E80E5 for ; Mon, 6 Aug 2012 12:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HxYgWy1SgvO for ; Mon, 6 Aug 2012 12:26:55 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBBB11E80E1 for ; Mon, 6 Aug 2012 12:26:55 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 882868A031 for ; Mon, 6 Aug 2012 19:26:54 +0000 (UTC) Date: Mon, 6 Aug 2012 15:26:52 -0400 From: Andrew Sullivan To: pkix@ietf.org Message-ID: <20120806192652.GO53917@mail.yitter.info> References: <1b2401cd7406$633cb0c0$29b61240$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b2401cd7406$633cb0c0$29b61240$@digicert.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] Concerns with draft-ietf-pkix-caa-10 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:26:55 -0000 Dear colleagues, On Mon, Aug 06, 2012 at 01:05:04PM -0600, Jeremy Rowley wrote: > Because there are a variety of instances where a DNS record might not > accurately reflect the appropriate issuing CA (such as improper updating, a > delay in display, etc.) and compliance with this RFC is entirely voluntary > by the CA community, the requirements in Section 3 should be changed from > "MUST" to "SHOULD" recommendations. I strongly disagree with that. The section is considering how CAA works for implementers. If a CA doesn't want to implement it, the MUST just doesn't have any effect. If there are problems with the operation of the DNS zone, it seems to me that the MUST becomes yet another constraint on that operation. SHOULD does not mean "oughta do this except when you don't". It means "you better have pretty good reasons not to do this". If the zone you're querying is wrong, you can't tell whether that's because the zone has been subverted, the zone is administered by numbskulls, or what. Therefore, if you're using CAA, you shouldn't issue (and if you're not using CAA, the MUST doesn't apply to you anyway). > I also think the section on using DNSSEC to authenticate CAA RRs needs > further development. The recommendation to use DNSSEC in connection with the > proposal would be strengthened significantly if the proposal required the > DNS record holder to maintain and make available an archive of DNS records > instead of issuing CAs. I don't understand this claim. What's the additional strength from this? What the zone looked like in the past is surely irrelevant to the current CAA query, no? > handle DNS records from those ordering digital certificates. In fact, these > roles are often not in the same country. This creates a > > probable point of failure by the implementers. This separation between > certificate requesters and DNS record controllers also increases the risk > that the criticality flag can be abused as the controllers may be unaware of > the variety of certificates uses within the enterprises. This sounds like an argument that, because people don't know how to operate their zones, we should make the protocol less rigorous. I cannot agree with such a proposal (any more than I think the proposals to use fudge-factor DNSSEC validation or, for that matter, long-expired A RRs are good ideas). If you want to put stuff in the DNS, you need to make sure you do it correctly. If you think your DNS department is too incompetent to use CAA correctly in your zone, don't use CAA at all. (I acknowledge, however, that "Don't use CAA at all," would be much happier advice if the only place the CAA record was checked was at the owner name itself, rather than using the tree-climbing crud the WG seems to want.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From kent@bbn.com Mon Aug 6 13:12:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292ED21E804C for ; Mon, 6 Aug 2012 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.514 X-Spam-Level: X-Spam-Status: No, score=-106.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7d4OLN+Vqjwm for ; Mon, 6 Aug 2012 13:12:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5D10911E809A for ; Mon, 6 Aug 2012 13:12:43 -0700 (PDT) Received: from dhcp89-089-055.bbn.com ([128.89.89.55]:58296) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SyTfO-000365-Vw for pkix@ietf.org; Mon, 06 Aug 2012 16:12:43 -0400 Message-ID: <5020253A.2030201@bbn.com> Date: Mon, 06 Aug 2012 16:12:42 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: pkix@ietf.org References: <501AB3A3.4020209@bbn.com> <20120804011634.GA25458@odin.ulthar.us> <5170CB53-0BE5-404B-B60B-B6EAE221D8CC@vpnc.org> <20120805010239.GA25950@odin.ulthar.us> In-Reply-To: <20120805010239.GA25950@odin.ulthar.us> Content-Type: multipart/alternative; boundary="------------090803080806040501010205" Subject: Re: [pkix] reminder X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 20:12:44 -0000 This is a multi-part message in MIME format. --------------090803080806040501010205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Scott, I tend to think of cert validation as equivalent to authentication of asserted identities, but I am in favor trying to make this as clear as possible. Your text drops the phrase "These certificates" which in intended to address the format part of the topic. So, how about: *"These certificates, and how a relying party uses them to authenticate the asserted identities (certificate validation), are both outside the scope of RFC 5280." * Steve --------------090803080806040501010205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Scott,

I tend to think of cert validation as equivalent to authentication of asserted
identities, but I am in favor trying to make this as clear as possible. Your text drops
the phrase "These certificates" which in intended to address the format part of the
topic. So, how about:

"These certificates, and how a relying party uses them to authenticate the asserted
identities (certificate validation), are both outside the scope of RFC 5280."

Steve


--------------090803080806040501010205-- From i.grok@comcast.net Mon Aug 6 18:44:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBA621F8505 for ; Mon, 6 Aug 2012 18:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEa0nBIEBcz8 for ; Mon, 6 Aug 2012 18:44:08 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 74F4121F8527 for ; Mon, 6 Aug 2012 18:44:08 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id jdeY1j00Y0QuhwU51dkBnZ; Tue, 07 Aug 2012 01:44:11 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta02.westchester.pa.mail.comcast.net with comcast id jdjt1j0062Ekl483Ndjvok; Tue, 07 Aug 2012 01:43:55 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id q771i5na005676 for ; Mon, 6 Aug 2012 21:44:05 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q771i55E005675 for pkix@ietf.org; Mon, 6 Aug 2012 21:44:05 -0400 Date: Mon, 6 Aug 2012 21:44:05 -0400 From: Scott Schmit To: pkix@ietf.org Message-ID: <20120807014404.GA5308@odin.ulthar.us> Mail-Followup-To: pkix@ietf.org References: <501AB3A3.4020209@bbn.com> <20120804011634.GA25458@odin.ulthar.us> <5170CB53-0BE5-404B-B60B-B6EAE221D8CC@vpnc.org> <20120805010239.GA25950@odin.ulthar.us> <5020253A.2030201@bbn.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <5020253A.2030201@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] reminder X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 01:44:09 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 06, 2012 at 04:12:42PM -0400, Stephen Kent wrote: > I tend to think of cert validation as equivalent to authentication of > asserted identities, but I am in favor trying to make this as clear as > possible. Your text drops the phrase "These certificates" which in > intended to address the format part of the topic. So, how about: No, I'm *trying* to exclude the formatting. Other RFCs refer to 5280 as a way to format certificates. I think it's legitimate to say that this formatting as defined by 5280 is in scope of 5280. (From what I read, the X.509 spec is unusuable on its own -- it needs a profiling specification like PKIX.) As I see it, the contention over self-signed non-CA certificates isn't their formatting, it's their validity/authentication. I'm trying to make those two issues distinct. --=20 Scott Schmit --0F1p//8PRICkK4MW Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQBAYJKoZIhvcNAQcCoIIP9TCCD/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DTUwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBvkwggXhoAMCAQICAwR4CjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDcwNDEz NTc1MVoXDTEzMDcwNTA1MjcyNlowQDEbMBkGA1UEAwwSaS5ncm9rQGNvbWNhc3QubmV0MSEw HwYJKoZIhvcNAQkBFhJpLmdyb2tAY29tY2FzdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCxn+QJTgdUJ1RAOi6JbFsDfl21ZX/OPx/ttuXWQP1vWwBZybHU+4/+bRXH 5ONhjbc5ikZvz/E406iQLy2xMT5PI/hx4uIZQQYpkjxd4rCbbvLNACz5L+cFaGj4WfGwAXDv bw4nx8Mh3WjbR5yjBCWYqadiv7HWAWmhaJmuaTp/e+mO2EEOOdoNQ8b2mxMyN43TlElx6Zos t7g/eQUcLWgTB5apPhowCCGnFU6uHK053QsPmsmZ67gg8acpb5ic0+P+X1j+IgD3jcsDzjrF TPlrvU4ZuBYQJISqngbc2ua/uutx75Xs4iFXWNRlnYfZMFJy96USzrhIBRqcORrjbyGXAgMB AAGjggOtMIIDqTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFAxkdHPHW3mhf+gXJjezdazgoDRuMB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmkuZ3Jva0Bjb21jYXN0Lm5ldDCC AiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBT ZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9h aWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBACJi0f4m 0bSVq+pq4AHeC2Rj4S8rciW+Uce6LC69UlyVMijKv/pZNFM08vqRXEI9WpKQhKXacJ+rK9az DBmnxq1scqKhn7991V6Yt2t0tEY8vUX7q330GybUB/rQLNrh66GFXaEWU/S692pGzvUXeV+w zz48snMpoMHQdxkHHW5sQkpo99SF/vOA5/sqvFmJ+ai1iDRjtKcChjkmAtFmCKv/dNrXnvew 5+QnLlnE/TsW4Sdv3bcLdlthD4eavS3BdgXfX7dfj0ykel53J2Us3CikNbyuCsJpwMH+gX1j LcXZOYIDLzZXCFEOFajhgsAZ5JQrW0fFRxjGIp8Rs+rxdFwxggKXMIICkwIBATCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEeAowCQYFKw4DAhoFAKCB2DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA4MDcwMTQ0MDRaMCMG CSqGSIb3DQEJBDEWBBTqt2vs9zUK5JMrdmOhzVs2U7YV1DB5BgkqhkiG9w0BCQ8xbDBqMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASCAQCddMW85AN6CjRHqR5LvizTYBl0Sn/d2zLH6okc0yndDDUaVQqwF07f R8aTY86rCCOvuoeOrDnZtzDhr+EQ3azroeC3ZkQCBgBF/PP/ShqIrY+RVWG7333eB/ZSoqU/ 9jc5Zkh9Sugb5pSu9+o0u2H85lW/c9HO3+lG15dxgBH4G5qzaD+loAYQTb++4KYQ7Tye/eXl BF2od6i1ApC1asMgnijn3mHF29SKrNtRNYmcKDC1+omYM0EHJkahmNLO1SN4QECMwzlYyieo zyHPlI6MBVdFIRLdGk8gk4CAqDAQJ1HPOuJanMpy1C15Vp+W4WJFXMVzdxVQYgIdZUmDHpo6 --0F1p//8PRICkK4MW-- From mrex@sap.com Mon Aug 6 22:58:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B020C21F8644 for ; Mon, 6 Aug 2012 22:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.848 X-Spam-Level: X-Spam-Status: No, score=-9.848 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gvcc7pz0gimG for ; Mon, 6 Aug 2012 22:58:52 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6DA21F85A8 for ; Mon, 6 Aug 2012 22:58:52 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q775woEU025215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Aug 2012 07:58:50 +0200 (MEST) In-Reply-To: <501A9D2C.6000704@nist.gov> To: "David A. Cooper" Date: Tue, 7 Aug 2012 07:58:50 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120807055850.37DCE1A125@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] 2560bis (essay version) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 05:58:53 -0000 David A. Cooper wrote: > > As you voted for option A in the straw poll, please provide Stefan with > this formal correctness proof so that he can address any aspects of the > protocol that are underspecified, in case future development of 2560bis > is based on option A. Myself, I don't do formal correctness proofs (I do not have such huge amounts of time at my disposition) [*]. But once you understand how formal correctness proofing works in principle, you can use the underlying methods to check some specification feature/protocol option for "obvious" defects (contradictions or ambiguities). Defects in a spec often cause interop problems. Sometimes defects will require a disambiguation before being implementable, but not all implementors ask for disambiguation, (ab)use a misspecified protocol option in the fashion they see fit and ship their implementation of it. And sometimes defects can be recognized and overcome by redundant information in the spec, but not all implementors are equally gifted in deducting what the spec should have correctly said. X.509 and PKIX contain so many inconsistencies and ambiguities that one will probably have to change or drop at least half of X.509 spec in order to obtain correctness. Considering the size and complexity of these specs, it looks like a multi-man-year effort to me. So what I'm doing about OCSP is looking at the "minimum requirements" OCSP client & responder, and which parts of the more complex options will cause interop problems with a high probability. -Martin [*] In 1996 a student from the University of Karlsruhe was doing his master thesis at my company, a tool-based formal correctness proof of a specific subset of our authorziation scheme. He was helping the developers to create the detailed specification, while he was doing the translation into predicate logic and updating the specification to accomodate for ambiguities and inconsistencies that the tool encountered. It took him 4 months. The tool that he used was "Karlsruhe Interactive Verifier (KIV)" Personally, I'm _not_ intimate with all the theory behind it, and was disappointed by the ROI, but I really liked the underlying principles and adopted them for spec-reviewing and programming and used them in 1996-1998 for reviewing the subset of GSS-API v2 (rfc2743/2744) that we use in our software. When I applied this methods in Nov 2009 to during discussion of TLS channel bindings on the TLS mailing list, after I had understood what Nico&Larry were trying to accomplish, I tried describing to them why their desired behaviour was incompatible with the existing TLS renegotiation as specified: http://www.ietf.org/mail-archive/web/tls/current/msg03922.html On my way home, it dawned on me that certain application designs might be blindly relying on a TLS protocol characteristic that really did not exist, and would likely be susceptible to MitM: http://www.ietf.org/mail-archive/web/tls/current/msg03928.html The TLS renegotiation MitM problem (and the full scope of the vulnerability) had been independently discovered 2 months earlier and resulted in a closed group secretly working on a fix: http://www.ietf.org/mail-archive/web/tls/current/msg03942.html And some 1500 messages later in the discussion, I gave a very rough sketch how to apply semi-formal logic to compare two different approaches to specify a protocol feature with each other: http://www.ietf.org/mail-archive/web/tls/current/msg05466.html From peter.sylvester@edelweb.fr Tue Aug 7 01:16:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C75321F866A for ; Tue, 7 Aug 2012 01:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FOSRquFHSsp for ; Tue, 7 Aug 2012 01:16:30 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5D32421F8647 for ; Tue, 7 Aug 2012 01:16:30 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 4BED85E169 for ; Tue, 7 Aug 2012 10:16:26 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 88CE384E36E for ; Tue, 7 Aug 2012 09:49:14 +0200 (CEST) Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id 5386F23633B for ; Tue, 7 Aug 2012 03:53:22 -0400 (EDT) Message-ID: <5020CEDE.9090100@edelweb.fr> Date: Tue, 07 Aug 2012 10:16:30 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: pkix@ietf.org References: <20120807055850.37DCE1A125@ld9781.wdf.sap.corp> In-Reply-To: <20120807055850.37DCE1A125@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] 2560bis (essay version) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 08:16:31 -0000 On 08/07/2012 07:58 AM, Martin Rex wrote: > > X.509 and PKIX contain so many inconsistencies and ambiguities > that one will probably have to change or drop at least half of X.509 spec > in order to obtain correctness. Considering the size and complexity > of these specs, it looks like a multi-man-year effort to me. > > This thread is about OCSP, not about X.509 or PKIX (aka 5280) isn't it? From kent@bbn.com Tue Aug 7 07:31:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE80D21F863F for ; Tue, 7 Aug 2012 07:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.515 X-Spam-Level: X-Spam-Status: No, score=-106.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LLjHem9Iqhc for ; Tue, 7 Aug 2012 07:31:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 85AC221F8685 for ; Tue, 7 Aug 2012 07:31:30 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38683 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sykof-000AAE-Iu; Tue, 07 Aug 2012 10:31:25 -0400 Message-ID: <502126BD.1040402@bbn.com> Date: Tue, 07 Aug 2012 10:31:25 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: i.grok@comcast.net References: <501AB3A3.4020209@bbn.com> <20120804011634.GA25458@odin.ulthar.us> <5170CB53-0BE5-404B-B60B-B6EAE221D8CC@vpnc.org> <20120805010239.GA25950@odin.ulthar.us> <5020253A.2030201@bbn.com> <20120807014404.GA5308@odin.ulthar.us> In-Reply-To: <20120807014404.GA5308@odin.ulthar.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] reminder X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 14:31:33 -0000 Scott, > No, I'm *trying* to exclude the formatting. Other RFCs refer to 5280 as > a way to format certificates. I think it's legitimate to say that this > formatting as defined by 5280 is in scope of 5280. (From what I read, > the X.509 spec is unusuable on its own -- it needs a profiling > specification like PKIX.) As I see it, the contention over self-signed > non-CA certificates isn't their formatting, it's their > validity/authentication. I'm trying to make those two issues distinct. Many folks, me included, believe that the formatting is not consistent with 5280, which is why we are going to the trouble of making this change. The formatting issue is that, in general, the issuer of a cert IS implicitly a CA, and thus a self-signed cert needs to contain a basic constraints extension, with the CA flag set TRUE. The certs that we are working to accommodate are not formatted consistent with this interpretation of 5280, hence the changed text. Since your motivation for the rewording is at odds with that, I'll retract my proposed change. Steve From mrex@sap.com Tue Aug 7 12:58:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A990011E8099 for ; Tue, 7 Aug 2012 12:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eg8FV3+4aO9e for ; Tue, 7 Aug 2012 12:58:09 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DAAA111E808A for ; Tue, 7 Aug 2012 12:58:08 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q77Jw1OQ021233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Aug 2012 21:58:06 +0200 (MEST) In-Reply-To: <5020CEDE.9090100@edelweb.fr> To: Peter Sylvester Date: Tue, 7 Aug 2012 21:58:00 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120807195800.D89DF1A12E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] 2560bis (essay version) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 19:58:09 -0000 Peter Sylvester wrote: > > Martin Rex wrote: >> >> X.509 and PKIX contain so many inconsistencies and ambiguities >> that one will probably have to change or drop at least half of X.509 spec >> in order to obtain correctness. Considering the size and complexity >> of these specs, it looks like a multi-man-year effort to me. > > This thread is about OCSP, not about X.509 or PKIX (aka 5280) isn't it? While this specific thread is about OCSP, OCSP is not an isolated piece of technology, but based on PKIX/rfc5280. You can not review the facier options of OCSP without including rfc5280&X.509 in the review. The carry-on container in OCSP for the OCSP signer certificate is a sequence of certificates, not a singular cert. So for the fancy options where the CA key/cert that signed the certificate under examination is neither the signer of the OCSP response, nor the signer of the OCSP signer cert, more than one cert may be required for the purpose of checking the OCSP signer cert for revocation. How to obtain the certs is *not* specified in rfc2560. Chasing AIA of a cert that hasn't been verified yet would be a serious vulnerability. At the moment I do not see any reasonable alternative to requiring the inclusion of all necessary certs in the the OCSP response. But rfc2560 does not mandate a particular ordering of the certs in the OCSP response, and how to build a certification path is explicitly outside of the scope of PKIX/rfc5280. "You are in a maze of twisty little passages, all alike" Reviewing a specification prior to implementing it means recognizing protocol options that are well-defined and where interop can reasonably be expected (when implemented by the peer), and distinguishing them from protocol options that are ambiguous/underspecified and/or partially out-of-scope is important, or you might see your expectations (about interop) differ from reality. I would appreciate when early adopters, who are pushing for a spec would do a careful review of the spec before it is finalized/published, so that the spec can be fixed/clarified before there is a huge installed base. Often they're primarily focused on specific usage scenarios on their minds, and whether the spec contains sufficient "slack" for their purposes & "creativity". -Martin From hallam@gmail.com Sat Aug 11 09:37:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0540521F853B for ; Sat, 11 Aug 2012 09:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.484 X-Spam-Level: X-Spam-Status: No, score=-5.484 tagged_above=-999 required=5 tests=[AWL=-1.885, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRnxMk3RdNf1 for ; Sat, 11 Aug 2012 09:37:53 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 245AB21F8535 for ; Sat, 11 Aug 2012 09:37:53 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4711367obb.31 for ; Sat, 11 Aug 2012 09:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pQ2W0Onooq78CMDT1mVNZorSxEEeQZRpN5lodG7O13g=; b=ElUy0RwPnwf2uD4sC+bmcKn9bfyklCcqmBIX6JrGnaCk1EJx7nBUClMtw8IqhrCXQL IEeidzcEoTkMlDgLixdLIGhAJ6UXkERbpMUKgle7iTwejsuIVC07nmvoCltySylF5B8g YtRyskUWdcoAiUP2wQVoxNj71hX4ZXVuy/l4VIOJGQdFgHS3m+58NlRYXL4CudVmSAKg XbTKLCBzW08GwRFIOFQN/6NCXcRIDViqPsNB8TgOZ/X9e6A/ZXwOXTARLmyHis8oTPj3 t89XPUq0QWaDnfo+/C6Vu9ZM6130ckAxXaIh+ipT4F+W+XInhIbl8ex4omcCOJF+EZ+0 ykng== MIME-Version: 1.0 Received: by 10.60.22.5 with SMTP id z5mr4280674oee.2.1344703072656; Sat, 11 Aug 2012 09:37:52 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Sat, 11 Aug 2012 09:37:52 -0700 (PDT) In-Reply-To: <20120806192652.GO53917@mail.yitter.info> References: <1b2401cd7406$633cb0c0$29b61240$@digicert.com> <20120806192652.GO53917@mail.yitter.info> Date: Sat, 11 Aug 2012 12:37:52 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix@ietf.org Subject: Re: [pkix] Concerns with draft-ietf-pkix-caa-10 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:37:54 -0000 As with all specifications, MUST means 'you must do this to be in compliance with this specification'. Hence CAA specifies MUST since they are normative. CAA is no more voluntary than any other IETF specification. CAs can choose to implement it or not but they may well find it more difficult to get their trust anchors embedded if they don't. CAs are in any case subject to an audit regime and so if they claim compliance and don't implement they can fail their audit. On Mon, Aug 6, 2012 at 3:26 PM, Andrew Sullivan wrote: > Dear colleagues, > > On Mon, Aug 06, 2012 at 01:05:04PM -0600, Jeremy Rowley wrote: > >> Because there are a variety of instances where a DNS record might not >> accurately reflect the appropriate issuing CA (such as improper updating, a >> delay in display, etc.) and compliance with this RFC is entirely voluntary >> by the CA community, the requirements in Section 3 should be changed from >> "MUST" to "SHOULD" recommendations. > > I strongly disagree with that. The section is considering how CAA > works for implementers. If a CA doesn't want to implement it, the > MUST just doesn't have any effect. If there are problems with the > operation of the DNS zone, it seems to me that the MUST becomes yet > another constraint on that operation. > > SHOULD does not mean "oughta do this except when you don't". It means > "you better have pretty good reasons not to do this". If the zone > you're querying is wrong, you can't tell whether that's because the > zone has been subverted, the zone is administered by numbskulls, or > what. Therefore, if you're using CAA, you shouldn't issue (and if > you're not using CAA, the MUST doesn't apply to you anyway). > >> I also think the section on using DNSSEC to authenticate CAA RRs needs >> further development. The recommendation to use DNSSEC in connection with the >> proposal would be strengthened significantly if the proposal required the >> DNS record holder to maintain and make available an archive of DNS records >> instead of issuing CAs. > > I don't understand this claim. What's the additional strength from > this? What the zone looked like in the past is surely irrelevant to > the current CAA query, no? > >> handle DNS records from those ordering digital certificates. In fact, these >> roles are often not in the same country. This creates a >> >> probable point of failure by the implementers. This separation between >> certificate requesters and DNS record controllers also increases the risk >> that the criticality flag can be abused as the controllers may be unaware of >> the variety of certificates uses within the enterprises. > > This sounds like an argument that, because people don't know how to > operate their zones, we should make the protocol less rigorous. I > cannot agree with such a proposal (any more than I think the proposals > to use fudge-factor DNSSEC validation or, for that matter, > long-expired A RRs are good ideas). If you want to put stuff in the > DNS, you need to make sure you do it correctly. If you think your DNS > department is too incompetent to use CAA correctly in your zone, don't > use CAA at all. (I acknowledge, however, that "Don't use CAA at all," > would be much happier advice if the only place the CAA record was > checked was at the owner name itself, rather than using the > tree-climbing crud the WG seems to want.) > > Best, > > A > > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ From hallam@gmail.com Sat Aug 11 09:47:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69E421F855B for ; Sat, 11 Aug 2012 09:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=-1.870, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29-LAI7lq3PK for ; Sat, 11 Aug 2012 09:47:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE6E721F853C for ; Sat, 11 Aug 2012 09:47:10 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4722958obb.31 for ; Sat, 11 Aug 2012 09:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sdfW5N+48xAQyhqdpKNIdk4I+bKqcLZY4ehnnfIX2yY=; b=yT0PGn5YpvEyIfJdC6peMlbdw4K9Msp2hhNlIVK6CLq02TDvIee8mvCyrQ0g0ocV5/ RKhXw+kGmI0nFCALQABQrLl1DvzKGftNhRV+BpKxKFNMNK/wVDML4HlG7pLSfY3TS2E1 OJp6g1ON6z/TqrdYf+0yNuX3h6tLi3nX2WqHEQ3xgbkC9ai4xhi2bWS7SDySsSctQtLl lvyC5aR805vBSCPOEfnL36G7REBg7SS1QIG66FQlvIhJ8vHkFYgD3VID2N550GmzeLU8 UyMaMprdj9fIYDgEEtAtZgIwYJdPZokdq9tcnH2oQ5urgEd2cXSuCy7iI4uEoLt2po8R ecuA== MIME-Version: 1.0 Received: by 10.182.89.102 with SMTP id bn6mr3013171obb.7.1344703630479; Sat, 11 Aug 2012 09:47:10 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Sat, 11 Aug 2012 09:47:10 -0700 (PDT) In-Reply-To: <080FBD5B7A09F845842100A6DE7962330ADC24D4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <501AAF29.9030307@DigiCert.com> <080FBD5B7A09F845842100A6DE7962330ADC24D4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Sat, 11 Aug 2012 12:47:10 -0400 Message-ID: From: Phillip Hallam-Baker To: "Bentkofsky, Michael" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" , Massimiliano Pala Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:47:12 -0000 There are pros and cons to using DNS. What we really need to do is to measure cases where DNS transport works but UDP does not and the cases where UDP transport works but DNS does not and see whether DNS is actually useful. The only potential benefit of using DNS is that it may be easier to get connectivity through firewalls. The potential benefit of using UDP is that an OCSP response could consist of one request packet and a series of response packets. That is probably enough to satisfy an reasonable OSCP transaction. The other design question is whether the client should query the responder of a CA or direct requests to a gateway chosen by the client (or client provider) that is known to meet an acceptable QoS. The problem I see with the OCSP over DNS approach is that the complaint from the browser providers is not merely that OCSP over HTTP is slow, it is that they are really unhappy with the reliability of some of the CA services. Now that might be possible to address if there was a consequence to having shitty OCSP service. I would like to see the padlock icon not show if the CA can't provide a decent responder. But they may not go for that. On Sun, Aug 5, 2012 at 6:16 PM, Bentkofsky, Michael wrote: > Hi Scott and Massimiliano, > > As someone who has implemented a very large OCSP service for a well-known= CA and implemented parts of the software infrastructure very large DNS ser= vice operator, I think your proposal has general merit. I have reviewed the= proposal although I am still thinking through some of the responses I've s= een so far and apparently have to catch-up on details such as RFC 4501. > > First, I would respond to the comments about overloading a DNS operation.= In my experience, DNS is significantly lighter than a TCP-based OCSP and w= ould take very considerably less computational (and likely network) resourc= es once implemented than an equivalent OCSP responder service. I've long th= ought, since the initial inception of the "lightweight OCSP profile" in RFC= 5019, that an even lighter way would be to use UDP. It has been my experie= nce that the TCP connection overhead is not only significant for increased = client latency, but also significant in the computational resources of the = servers. > > Besides the possibility of using UDP to reduce latency, I see the ability= to use anycasting, quite typical in DNS service providers, to be a viable = option for distributing load. In earlier experiments, I have noticed that a= nycasting TCP services does not work well for some clients, most likely due= to network misconfiguration. That data point is now a few years old. > > I do have a one question when I was reading through your proposal text. I= t sounds like you are considering the DNS query as between the client direc= tly to the CA's DNS service. Why not make use of the distributed nature of = the DNS to make the request to a local resolver and possibly get the advant= age of local caching? That is a more typical model for DNS (e.g. make a req= uest to a local resolver; local resolver makes recursive requests to author= itative servers). My only observation about this approach is that using a "= dnssec" URI doesn't make sense since local resolvers will do the DNSSEC val= idation, not the client. > > One potential downside I see is with the security guarantees. It is prett= y easy to forge UDP responses, and although the OCSP response is signed, on= e could invent cases where "OCSP good" responses were replayed (when the ce= rtificate had been revoked, but was still within the OCSP expiration window= ) or worse: the unsigned "Unknown" response could be blasted much easier th= an if the service were implemented over TCP. > > That all said, I'm on board in concept. > > Thanks, > > Michael > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of S= cott Rea > Sent: Thursday, August 02, 2012 12:48 PM > To: pkix@ietf.org > Subject: [pkix] OCSP over DNS > > G'day Folks, > > yesterday at PKIX we had some folks supporting the proposed OCSP over > DNS protocol (see: > https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/) and some > folks who said they did not like the idea. Time was short and I failed > to get further feedback from the folks who "hated" (yes that was the > exact phrase that was used) the idea as to WHY they do not support the > idea. > Would those folks be willing to post their objections/justifications to > the list, and if are not quite ready to make a public declaration, > please send Max or I an email directly off-list as to reasons why you > would not support this proposal? > > Scott Rea or > Massimiliano Pala > > Regards, > > -- > Scott Rea > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From kent@bbn.com Tue Aug 14 09:56:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F119121F8540 for ; Tue, 14 Aug 2012 09:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.774 X-Spam-Level: X-Spam-Status: No, score=-105.774 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25LpkajZ4sw7 for ; Tue, 14 Aug 2012 09:56:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5BC21F853A for ; Tue, 14 Aug 2012 09:56:01 -0700 (PDT) Received: from dhcp89-089-055.bbn.com ([128.89.89.55]:50232) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T1KPP-00007R-U5 for pkix@ietf.org; Tue, 14 Aug 2012 12:55:59 -0400 Message-ID: <502A831F.9060503@bbn.com> Date: Tue, 14 Aug 2012 12:55:59 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: pkix Content-Type: multipart/alternative; boundary="------------010002060703080109060400" Subject: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 16:56:03 -0000 This is a multi-part message in MIME format. --------------010002060703080109060400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The results of the straw poll (which closed on Sunday are below. recall that the options were: A - continue to work with the -05 version as the basis for an RFC B - revert to the -04 version as the basis for an RFC C - don't publish a clarifications document for OCSP D - the respondent volunteers to work on a new version of 2560bis Name A B C D Mike Myers 1 Russ Housley 1 Santosh 1 Stephen Farrell 1 Stefan 1 David Cooper 1 Martin Rex 1 Tim Polk 1 Peter Yee 1 Simon Josephson 1 Denis Pinkas 1 Steve Kent 1 TOTAL 8 3 0 1 So, we will proceed with the -05 version of the I-D. Steve --------------010002060703080109060400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The results of the straw poll (which closed on Sunday are below.

recall that the options were:


    A - continue to work with the -05 version as the basis for an RFC
    B - revert to the -04 version as the basis for an RFC
    C - don't publish a clarifications document for OCSP
    D - the respondent volunteers to work on a new version of 2560bis

Name A B C D
Mike Myers 1


Russ Housley 1


Santosh
1

Stephen Farrell 1


Stefan 1


David Cooper
1

Martin Rex 1


Tim Polk
1

Peter Yee 1


Simon Josephson 1


Denis Pinkas


1
Steve Kent 1












TOTAL 8 3 0 1


So, we will proceed with the -05 version of the I-D.

Steve
--------------010002060703080109060400-- From hotz@jpl.nasa.gov Tue Aug 14 14:15:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4480921F8659 for ; Tue, 14 Aug 2012 14:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlzdIZq9gGNu for ; Tue, 14 Aug 2012 14:15:28 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id C513921F8658 for ; Tue, 14 Aug 2012 14:15:28 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7ELFM2o003944 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 14 Aug 2012 14:15:23 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <502A831F.9060503@bbn.com> Date: Tue, 14 Aug 2012 14:15:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <502A831F.9060503@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 21:15:29 -0000 On Aug 14, 2012, at 9:55 AM, Stephen Kent wrote: > The results of the straw poll (which closed on Sunday are below. >=20 > recall that the options were: >=20 >=20 > A - continue to work with the -05 version as the basis for an RFC=20= > B - revert to the -04 version as the basis for an RFC=20 > C - don't publish a clarifications document for OCSP=20 > D - the respondent volunteers to work on a new version of 2560bis=20= >=20 > Name A B C D > Mike Myers 1=09 > Russ Housley 1=09 > Santosh 1=09 > Stephen Farrell 1 > Stefan 1 > David Cooper 1 > Martin Rex 1 > Tim Polk 1 > Peter Yee 1 > Simon Josephson 1 > Denis Pinkas 1 > Steve Kent 1 >=20 >=20 >=20 > TOTAL 8 3 0 1 >=20 > So, we will proceed with the -05 version of the I-D. >=20 > Steve Not to cause trouble, and meaning no slight to Stefan: I note that there = was no way to vote for Denis as opposed to oneself to create a new, = alternate version. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From kent@bbn.com Tue Aug 14 14:40:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAA221F8629 for ; Tue, 14 Aug 2012 14:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.502 X-Spam-Level: X-Spam-Status: No, score=-106.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTBo00aP5lMC for ; Tue, 14 Aug 2012 14:40:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9A821F8628 for ; Tue, 14 Aug 2012 14:40:52 -0700 (PDT) Received: from dhcp89-089-055.bbn.com ([128.89.89.55]:51490) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T1Or5-0009ZD-9f; Tue, 14 Aug 2012 17:40:51 -0400 Message-ID: <502AC5E2.3000801@bbn.com> Date: Tue, 14 Aug 2012 17:40:50 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Henry B. Hotz" References: <502A831F.9060503@bbn.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 21:40:53 -0000 Henry, Your observation is accurate, but no one objected to the options when I posted them. Also, during the course of the poll, there were several "essay" responses, none of which suggested that course of action. So, I don't see a need to revisit this topic at this point. Steve From stefan@aaa-sec.com Tue Aug 14 22:34:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F6811E80A5 for ; Tue, 14 Aug 2012 22:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgB-zypv+Uc7 for ; Tue, 14 Aug 2012 22:34:18 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id EFBFE11E809C for ; Tue, 14 Aug 2012 22:34:17 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 129B31DAC814 for ; Wed, 15 Aug 2012 07:34:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LA0Zzj0YqCfV for ; Wed, 15 Aug 2012 07:34:13 +0200 (CEST) Received: from s326.loopia.se (new-s34.loopia.se [194.9.94.94]) by s87.loopia.se (Postfix) with ESMTP id C74791DAC801 for ; Wed, 15 Aug 2012 07:34:13 +0200 (CEST) Received: (qmail 8951 invoked from network); 15 Aug 2012 05:34:13 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.213]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 15 Aug 2012 05:34:13 -0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Wed, 15 Aug 2012 07:34:11 +0200 From: Stefan Santesson To: Scott Rea , Message-ID: Thread-Topic: [pkix] OCSP over DNS In-Reply-To: <501AAF29.9030307@DigiCert.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:34:19 -0000 Scott, How is this proposal positioned in relation to OCSP stapling. Would we need either or, or both? I've seen two questions on what RRTYPE you would use, whether a new need to be defined and what deployment issues that would bring to the table. What is your position on that? /Stefan On 12-08-02 9:47 AM, "Scott Rea" wrote: >G'day Folks, > >yesterday at PKIX we had some folks supporting the proposed OCSP over >DNS protocol (see: >https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/) and some >folks who said they did not like the idea. Time was short and I failed >to get further feedback from the folks who "hated" (yes that was the >exact phrase that was used) the idea as to WHY they do not support the >idea. >Would those folks be willing to post their objections/justifications to >the list, and if are not quite ready to make a public declaration, >please send Max or I an email directly off-list as to reasons why you >would not support this proposal? > >Scott Rea or >Massimiliano Pala > >Regards, > >-- >Scott Rea > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Tue Aug 14 22:45:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA90321E80EA for ; Tue, 14 Aug 2012 22:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.037 X-Spam-Level: X-Spam-Status: No, score=-103.037 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjEa3BeNGODq for ; Tue, 14 Aug 2012 22:45:43 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCF821E80C0 for ; Tue, 14 Aug 2012 22:45:43 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 75CA71DAC805 for ; Wed, 15 Aug 2012 07:45:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dbTiua_2_M7R for ; Wed, 15 Aug 2012 07:45:42 +0200 (CEST) Received: from s329.loopia.se (new-s34.loopia.se [194.9.94.94]) by s87.loopia.se (Postfix) with ESMTP id 420281DAC7EC for ; Wed, 15 Aug 2012 07:45:42 +0200 (CEST) Received: (qmail 94773 invoked from network); 15 Aug 2012 05:45:41 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.213]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s329.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 15 Aug 2012 05:45:41 -0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Wed, 15 Aug 2012 07:45:39 +0200 From: Stefan Santesson To: pkix Message-ID: Thread-Topic: Use of the OSCP unknown response In-Reply-To: <502AC5E2.3000801@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:45:43 -0000 Note: This question is not about chaining OCSP. It is about what would be compliant with the current spec. I'm having some exchange with members of CAB forum regarding their use of OCSP. They want to require OCSP responders belonging to compliant CAs to NOT return a "good" response unless they have a record of the certificate being asked about. It seems to me that it would be perfectly in line with current OCSP spec to return "unknown" in case the CA has no record of the certificate being asked about. Current text from RFC 2560: The "unknown" state indicates that the responder doesn't know about the certificate being requested. Does anyone have a different opinion? /Stefan From denis.pinkas@bull.net Wed Aug 15 00:17:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9053421F85C7 for ; Wed, 15 Aug 2012 00:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccWhVjmc39Va for ; Wed, 15 Aug 2012 00:17:20 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE7E21F8468 for ; Wed, 15 Aug 2012 00:17:19 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id B1B7F18005; Wed, 15 Aug 2012 09:17:17 +0200 (CEST) In-Reply-To: <502AC5E2.3000801@bbn.com> References: <502A831F.9060503@bbn.com> <502AC5E2.3000801@bbn.com> To: Stephen Kent , "Henry B. Hotz" MIME-Version: 1.0 X-KeepSent: A228EF78:8AA3A55C-C1257A5B:002252A9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 15 Aug 2012 09:17:16 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 15/08/2012 09:17:17, Serialize complete at 15/08/2012 09:17:17 Content-Type: multipart/alternative; boundary="=_alternative 0028013EC1257A5B_=" Cc: pkix Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 07:17:20 -0000 Message en plusieurs parties au format MIME --=_alternative 0028013EC1257A5B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable For of all, thank you Henry for your posting. Steve, do you mean that it is possible to object when the chairs are=20 proposing a straw poll ? I was not thinking it was ever possible, so I did not objected. Steve, you said:=20 "Also, during the course of the poll, there were several "essay"=20 responses, none of which suggested that course of action". This is not quite true. On August 6, I wrote to the list: "I hope to be able to deliver such a new version within two weeks=20 from now. I plan to add explanations: =20 - for OCSP clients when they build a request, - for OCSP clients when they verify a response. (...) I plan to work from version -05 which is not "good enough", but=20 much better than version -04 with all its annexes." Two weeks from August 6 means August 20. I have already spent about 20 hours to prepare this document starting from = version -05. .i.e. one of the two proposed versions of the strawpol (and the one which=20 won the strawpol). In fact, I did a lot more than the announced explanations, including=20 additional text in=20 the security considerations section. The changes, mostly additional text,=20 will be indicated=20 at the beginning of the document. The draft document is currently still being reviewed by a few people=20 within my company. I still hope to be able to post it close to August 20. On August 10, the co-chairs privately received an intermediate copy of the = draft, so they could start=20 to build their own opinion about the improvements made, but I have=20 received no private response from=20 the co-chairs yet at this time. The question for me, at the time being, is whether I can post the drat as=20 : draft-ietf-pkix-rfc2560bis-06 or whether I should post it as : draft-ietf-pinkas-rfc2560bis-00 Steve, would you please provide an answer to that question ? Denis=20 De : Stephen Kent A : "Henry B. Hotz" Cc : pkix Date : 14/08/2012 23:40 Objet : Re: [pkix] 2560bis Envoy=E9 par : pkix-bounces@ietf.org Henry, Your observation is accurate, but no one objected to the options when I=20 posted them. Also, during the course of the poll, there were several "essay"=20 responses, none of which suggested that course of action. So, I don't see a need to revisit this topic at this point. Steve =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 0028013EC1257A5B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable For of all, thank you Henry for your posting.=

Steve, do you mean that it is possible to object when the chairs are proposing a straw poll ?
I was not thinking it was ever possible, so I did not objected.

Steve, you said:

"Also, during the course of the poll, there were several "essay"
responses, none of which suggested that course of action".

This is not quite true. On August 6, I wr= ote to the list:

        "I hope to be able to deliver such a new version within two weeks from now.

        I plan to add explanations:
                       - for OCSP clients when they build a request,
                 - for OCSP clients when they verify a response.
        (...)

        I plan to work from version -05 which is not "good enough", but
       much better than version -04 with all its annexes."

Two weeks from August 6 means August 20.<= /font>

I have already spent about 20 hours to pr= epare this document starting from version -05.
.i.e. one of the two proposed versions of the strawpol (and the one which won the strawpol).

In fact, I did a lot more than the announ= ced explanations, including additional text in
the security considerations section. The changes, mostly additional text, will be indicated
at the beginning of the document.

The draft document is currently still bei= ng reviewed by a few people within my company.

I still hope to be able to post it close to August 20.

On August 10, the co-chairs privately rec= eived an intermediate copy of the draft, so they could start
to build their own opinion about the improvements made, but I have received no private response from
the co-chairs yet at this time.

The question for me, at the time being, is whether I can post the drat as :

      draft-ietf-pkix-rfc2= 560bis-06

or whether I should post it as :

      draft-ietf-pinkas-rf= c2560bis-00

Steve, would you please provide an answer to that question ?

Denis



De :     &= nbsp;  Stephen Kent <kent@bbn.c= om>
A :     &n= bsp;  "Henry B. Hotz" <hotz@jpl.nasa.gov>
Cc :   &nb= sp;    pkix <pkix@ietf.o= rg>
Date :    =    14/08/2012 23:40
Objet :        Re: [pkix] 2560bis
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



Henry,

Your observation is accurate, but no one objected to the options when I
posted
them. Also, during the course of the poll, there were several "essay&q= uot;
responses,
none of which suggested that course of action.

So, I don't see a need to revisit this topic at this point.

Steve

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 0028013EC1257A5B_=-- From simon@tardell.se Wed Aug 15 01:14:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599C421F85CE for ; Wed, 15 Aug 2012 01:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQdmOClwMdto for ; Wed, 15 Aug 2012 01:14:38 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8B621F8717 for ; Wed, 15 Aug 2012 01:14:36 -0700 (PDT) Received: by lahm15 with SMTP id m15so718040lah.31 for ; Wed, 15 Aug 2012 01:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tardell.se; s=delta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ASNfRJI0palcWrrGO7qmGoEIunxeTonP1fXenoqP0uw=; b=hFUmcplUBBMeDYQ2DFYfN8bOuJNJbJvQw84Ny/nzTyOhNy3EBY7ORx2PAKRj+6l8ue pFkbQTVV45EhJ50fWDuA7M0tkmltFTgybYAZNASDIbTCJBokVwdIdQ4bRHpGMPc0fbyW xIrSwTixRLz2rGWYLeH/g1W8WXIndhMWNv6tU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ASNfRJI0palcWrrGO7qmGoEIunxeTonP1fXenoqP0uw=; b=VjljUZFrblvQ0eVeqFmQH0HK+zzi3SMzzMOtepKZZDRKXO3px2zrjvBa8SiDgvNPp1 9BEOOFP00X0GcY3KNeFo9FCNaANM4RH6tXsU3vMFB8vvIZxAA25lFYH1o06smv4aLtrM qwoIt+n5eJVB7JAfK8aSTrg9D5la/mXUtJ4LwcChK104KltvBd2YzBe7i086y9m/lX5f 1YvXlbVAxglM5w0TipOaWbke/VDhdWVSDyAvondKBeMeV9Lu6SGmMgtqz6dIrlVr5hgh aRF/nYeiVSJUcdEw+0UbdJaFM6rH/T4ICGVvEZBs7MQT1hQNmkMuROLaabn1KLfcNyMi WFbw== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr15201067lab.41.1345018475138; Wed, 15 Aug 2012 01:14:35 -0700 (PDT) Received: by 10.112.46.131 with HTTP; Wed, 15 Aug 2012 01:14:35 -0700 (PDT) In-Reply-To: References: <502AC5E2.3000801@bbn.com> Date: Wed, 15 Aug 2012 10:14:35 +0200 Message-ID: From: Simon Tardell To: Stefan Santesson Content-Type: multipart/alternative; boundary=f46d043bd6fa6d4cea04c749849f X-Gm-Message-State: ALoCoQmvcfLNmIvNc0Gljr+yiZ4gmFodVkTFVjbyjGr5fM15f/pRch+MGWU0Sc9wnS18G6WIid7K Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 08:14:39 -0000 --f46d043bd6fa6d4cea04c749849f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Skickat fr=E5n min iPad 15 aug 2012 kl. 07:45 skrev Stefan Santesson : > Note: This question is not about chaining OCSP. It is about what would be > compliant with the current spec. > > > > > I'm having some exchange with members of CAB forum regarding their use of > OCSP. > > They want to require OCSP responders belonging to compliant CAs to NOT > return a "good" response unless they have a record of the certificate > being asked about. > > It seems to me that it would be perfectly in line with current OCSP spec > to return "unknown" in case the CA has no record of the certificate being > asked about. > > Current text from RFC 2560: > The "unknown" state indicates that the responder doesn't know about > the certificate being requested. > > > > Does anyone have a different opinion? :) Yes. This is the perennial debate, since the early days of OCSP. There are actually two discussions. 1/ should we at all allow the issuance question to be answered in the protocol 2/ if we do, how should it be expressed? There are good arguments both ways regarding 1, but I feel we should, and doing that answer 2 just to put this dead horse to rest once and for all. In my mind the three possible responses are "good", "bad" and "don't know, ask someone else if you really want to know". Granted, the wording of the "unknown" definition is a bit vague, but it cannot be read as an affirmative response about the non-existence of a certificate. The real problem is that "bad" is labeled "revoked" in the document and defined only as such. The "good" definition on the other hand foresees the issuance question: The "good" state indicates a positive response to the status inquiry. > At a minimum, this positive response indicates that the certificate > is not revoked, but does not necessarily mean that the certificate > was ever issued or that the time at which the response was produced > is within the certificate's validity interval. Response extensions > may be used to convey additional information on assertions made by > the responder regarding the status of the certificate such as > positive statement about issuance, validity, etc. My position is that reading "unknown" as an assertion of non-issuance is contrived. It is more reasonable to read it as "...the responder doesn't know about [the status of] the certificate requested" (as in I can't map the CertID to any CA, or I am temporarily offline with regards to that CA). Looks very much more like an editing error than anything else. The client can only do three thing as a result of an OCSP response: accept the certificate, reject it, or try to get better information later or at some other place. There is little point in having two "reject" responses, especially if it comes at the expense of the "try-somewhere-else-or-come-back-later-if-you-have-time" response. I propose that we resolve this by defining the extension that the "good" definition talks about, and changing the label of "revoked" to be "bad". I suggest that if you want the responder to answer the question about issuance, you use a single request extension to signal that. And if you want to answer the question, you answer good if it is issued and not revoked or bad/revoked if it is non-issued with reason code certificate hold and an invalidity date at the beginning of time; adding a single response extension in both cases to show that you have considered the issuance question. The exact syntax of the single request/response extension can be discussed, but it potentially could include a hash of the certificate at hand. This would leave us with three orthogonal response states: "good"/"bad"/"don't-know" and clear out a lot of confusion. /Simon > /Stefan > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --f46d043bd6fa6d4cea04c749849f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Skickat fr=E5n min iPad

15 aug 2012 kl. 07:45 skrev Stefan S= antesson <stefan= @aaa-sec.com>:

> Note: This question is not about chaining= OCSP. It is about what would be
> compliant with the current spec.
>
>
>
> > I'm having some exchange with members of CAB forum regarding the= ir use of
> OCSP.
>
> They want to require OCSP responde= rs belonging to compliant CAs to NOT
> return a "good" response unless they have a record of the ce= rtificate
> being asked about.
>
> It seems to me that i= t would be perfectly in line with current OCSP spec
> to return "= ;unknown" in case the CA has no record of the certificate being
> asked about.
>
> Current text from RFC 2560:
> =A0T= he "unknown" state indicates that the responder doesn't know = about
> =A0the certificate being requested.
>
>
>=
> Does anyone have a different opinion?

:)

Yes. This is th= e perennial debate, since the early days of OCSP.

There are actuall= y two discussions. 1/ should we at all allow the issuance question to be an= swered in the protocol 2/ if we do, how should it be expressed? There are g= ood arguments both ways regarding 1, but I feel we should, and doing that a= nswer 2 just to put this dead horse to rest once and for all.

In my mind the three possible responses are "good", "bad= " and "don't know, ask someone else if you really want to kno= w". Granted, the wording of the "unknown" definition is a bi= t vague, but it cannot be read as an affirmative response about the non-exi= stence of a certificate. The real problem is that "bad" is labele= d "revoked" in the document and defined only as such. The "g= ood" definition on the other hand foresees the issuance question:

=A0 =A0The "good" state indicates a positive= response to the status inquiry.
=A0 =A0At a minimum, this positive response indicates that the certificate<= br>=A0 =A0is not revoked, but does not necessarily mean that the certificat= e
=A0 =A0was ever issued or that the time at which the response was prod= uced
=A0 =A0is within the certificate's validity interval. Response extensio= ns
=A0 =A0may be used to convey additional information on assertions mad= e by
=A0 =A0the responder regarding the status of the certificate such a= s
=A0 =A0positive statement about issuance, validity, etc.

My position is that reading "unknown" as an assertion of non-= issuance is contrived. It is more reasonable to read it as "...the res= ponder doesn't know about [the status of] the certificate requested&quo= t; (as in I can't map the CertID to any CA, or I am temporarily offline= with regards to that CA). Looks very much more like an editing error than = anything else.

The client can only do three thing as a result of an OCSP response: acc= ept the certificate, reject it, or try to get better information later or a= t some other place. There is little point in having two "reject" = responses, especially if it comes at the expense of the "try-somewhere= -else-or-come-back-later-if-you-have-time" response.

I propose that we resolve this by defining the extension that the "= ;good" definition talks about, and changing the label of "revoked= " to be "bad". I suggest that if you want the responder to a= nswer the question about issuance, you use a single request extension to si= gnal that. And if you want to answer the question, you answer good if it is= issued and not revoked or bad/revoked if it is non-issued with reason code= certificate hold and an invalidity date at the beginning of time; adding a= single response extension in both cases to show that you have considered t= he issuance question. The exact syntax of the single request/response exten= sion can be discussed, but it potentially could include a hash of the certi= ficate at hand.

This would leave us with three orthogonal response states: &= quot;good"/"bad"/"don't-know" and clear out a = lot of confusion.

/Simon

> /Stefan
>
>
> ____________________________________= ___________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/= listinfo/pkix
--f46d043bd6fa6d4cea04c749849f-- From tomasg@primekey.se Wed Aug 15 01:36:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993E521F86F2 for ; Wed, 15 Aug 2012 01:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGOiJ8C7kVSy for ; Wed, 15 Aug 2012 01:36:05 -0700 (PDT) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1D92D21F84D3 for ; Wed, 15 Aug 2012 01:36:05 -0700 (PDT) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id B91DDE1BEC for ; Wed, 15 Aug 2012 10:36:03 +0200 (CEST) Received: from [192.168.3.193] (37-247-8-250.customers.ownit.se [37.247.8.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id A937EE1BBC for ; Wed, 15 Aug 2012 10:36:03 +0200 (CEST) Message-ID: <502B5F73.2040009@primekey.se> Date: Wed, 15 Aug 2012 10:36:03 +0200 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 08:36:05 -0000 On 08/15/2012 07:45 AM, Stefan Santesson wrote: > Note: This question is not about chaining OCSP. It is about what would be > compliant with the current spec. > > > > > I'm having some exchange with members of CAB forum regarding their use of > OCSP. > > They want to require OCSP responders belonging to compliant CAs to NOT > return a "good" response unless they have a record of the certificate > being asked about. > > It seems to me that it would be perfectly in line with current OCSP spec > to return "unknown" in case the CA has no record of the certificate being > asked about. > > Current text from RFC 2560: > The "unknown" state indicates that the responder doesn't know about > the certificate being requested. > > > > Does anyone have a different opinion? I agree with you. For a responder this is definitely in line with the spec. Regards, Tomas From rob.stradling@comodo.com Wed Aug 15 01:42:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A19F21F875D for ; Wed, 15 Aug 2012 01:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1LKEOhSRDRJ for ; Wed, 15 Aug 2012 01:42:30 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id A037421F876A for ; Wed, 15 Aug 2012 01:42:29 -0700 (PDT) Received: (qmail 31566 invoked from network); 15 Aug 2012 08:42:28 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 15 Aug 2012 08:42:28 -0000 Received: (qmail 30100 invoked by uid 1000); 15 Aug 2012 08:42:27 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 15 Aug 2012 09:42:27 +0100 Message-ID: <502B606C.40504@comodo.com> Date: Wed, 15 Aug 2012 09:40:12 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Simon Tardell References: <502AC5E2.3000801@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stefan Santesson , pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 08:42:31 -0000 On 15/08/12 09:14, Simon Tardell wrote: > I propose that we resolve this by defining the extension that the "good" > definition talks about http://tools.ietf.org/html/draft-hallambaker-ocspdigest > , and changing the label of "revoked" to be "bad". If a label change is permitted (in 2560bis), I'd prefer to see "good" changed to "not revoked". -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From stefan@aaa-sec.com Wed Aug 15 02:15:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1843F21F876A for ; Wed, 15 Aug 2012 02:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1XcQMaGQpOy for ; Wed, 15 Aug 2012 02:15:57 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id AAA0521F8766 for ; Wed, 15 Aug 2012 02:15:56 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 7DE851DAE141 for ; Wed, 15 Aug 2012 11:14:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2Lhgoh6kXwfy for ; Wed, 15 Aug 2012 11:14:11 +0200 (CEST) Received: from s327.loopia.se (new-s34.loopia.se [194.9.94.94]) by s87.loopia.se (Postfix) with ESMTP id 913821DAE134 for ; Wed, 15 Aug 2012 11:14:11 +0200 (CEST) Received: (qmail 53122 invoked from network); 15 Aug 2012 09:14:11 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 15 Aug 2012 09:14:11 -0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Wed, 15 Aug 2012 11:14:09 +0200 From: Stefan Santesson To: Simon Tardell Message-ID: Thread-Topic: [pkix] Use of the OSCP unknown response In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3427874052_18922405" Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 09:15:58 -0000 > 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. --B_3427874052_18922405 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Simon, Your read more into my question than I asked (or proposed). I never asked/suggested that the unknown response should be interpreted as = a confirmation that the certificate was never issued. The question was whether it would be conformant to send the "unknown" response if the cert has never been issued. Do you see the difference? In the context of my question, the client would not know that the certificate was never issued. It would simply know that the responder don't know about the cert for any given reason you mention. Yes I agree we would need an extension to signal (if at all) an explicit confirmation that the certificate was never issued. The question is still what response that could be returned if that extension states that the certificate was never issued. There are only three to choose from good, revoked and unknown. It seems to me that "unknown" is the only reasonable alternative as both "good" and "revoked" are clearly wrong. /Stefan From: Simon Tardell Date: Wednesday, 15 August, 2012 10:14 AM To: Stefan Santesson Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response >=20 >=20 > Skickat fr=E5n min iPad >=20 > 15 aug 2012 kl. 07:45 skrev Stefan Santesson : >=20 >> > Note: This question is not about chaining OCSP. It is about what would= be >> > compliant with the current spec. >> >=20 >> >=20 >> >=20 >> >=20 >> > I'm having some exchange with members of CAB forum regarding their use= of >> > OCSP. >> >=20 >> > They want to require OCSP responders belonging to compliant CAs to NOT >> > return a "good" response unless they have a record of the certificate >> > being asked about. >> >=20 >> > It seems to me that it would be perfectly in line with current OCSP sp= ec >> > to return "unknown" in case the CA has no record of the certificate be= ing >> > asked about. >> >=20 >> > Current text from RFC 2560: >> > The "unknown" state indicates that the responder doesn't know about >> > the certificate being requested. >> >=20 >> >=20 >> >=20 >> > Does anyone have a different opinion? >=20 > :) >=20 > Yes. This is the perennial debate, since the early days of OCSP. >=20 > There are actually two discussions. 1/ should we at all allow the issuanc= e > question to be answered in the protocol 2/ if we do, how should it be > expressed? There are good arguments both ways regarding 1, but I feel we > should, and doing that answer 2 just to put this dead horse to rest once = and > for all. >=20 > In my mind the three possible responses are "good", "bad" and "don't know= , ask > someone else if you really want to know". Granted, the wording of the > "unknown" definition is a bit vague, but it cannot be read as an affirmat= ive > response about the non-existence of a certificate. The real problem is th= at > "bad" is labeled "revoked" in the document and defined only as such. The > "good" definition on the other hand foresees the issuance question: >=20 >> The "good" state indicates a positive response to the status inquiry. >> At a minimum, this positive response indicates that the certificate >> is not revoked, but does not necessarily mean that the certificate >> was ever issued or that the time at which the response was produced >> is within the certificate's validity interval. Response extensions >> may be used to convey additional information on assertions made by >> the responder regarding the status of the certificate such as >> positive statement about issuance, validity, etc. >=20 > My position is that reading "unknown" as an assertion of non-issuance is > contrived. It is more reasonable to read it as "...the responder doesn't = know > about [the status of] the certificate requested" (as in I can't map the C= ertID > to any CA, or I am temporarily offline with regards to that CA). Looks ve= ry > much more like an editing error than anything else. >=20 > The client can only do three thing as a result of an OCSP response: accep= t the > certificate, reject it, or try to get better information later or at some > other place. There is little point in having two "reject" responses, > especially if it comes at the expense of the > "try-somewhere-else-or-come-back-later-if-you-have-time" response. >=20 > I propose that we resolve this by defining the extension that the "good" > definition talks about, and changing the label of "revoked" to be "bad". = I > suggest that if you want the responder to answer the question about issua= nce, > you use a single request extension to signal that. And if you want to ans= wer > the question, you answer good if it is issued and not revoked or bad/revo= ked > if it is non-issued with reason code certificate hold and an invalidity d= ate > at the beginning of time; adding a single response extension in both case= s to > show that you have considered the issuance question. The exact syntax of = the > single request/response extension can be discussed, but it potentially co= uld > include a hash of the certificate at hand. >=20 > This would leave us with three orthogonal response states: > "good"/"bad"/"don't-know" and clear out a lot of confusion. >=20 > /Simon >=20 >> > /Stefan >> >=20 >> >=20 >> > _______________________________________________ >> > pkix mailing list >> > pkix@ietf.org >> > https://www.ietf.org/mailman/listinfo/pkix --B_3427874052_18922405 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Simon,

Your read more into my question than I asked (or proposed).

I never asked/suggested that the unknown response should be = interpreted as a confirmation that the certificate was never issued.
The question was whether it would be conformant to send the "unknown" res= ponse if the cert has never been issued.

Do you see= the difference?

In the context of my question, the= client would not know that the certificate was never issued. It would simpl= y know that the responder don't know about the cert for any given reason you= mention.

Yes I agree we would need an extension to= signal (if at all) an explicit confirmation that the certificate was never = issued. The question is still what response that could be returned if that e= xtension states that the certificate was never issued.

<= div>There are only three to choose from good, revoked and unknown. It seems = to me that "unknown" is the only reasonable alternative as both "good" and "= revoked" are clearly wrong.

/Stefan

<= /div>

From: Simon Tardell = <simon@tardell.se>
Date: Wednesday, 15 August, 2012 10:14 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: pkix <pkix@ietf.org= >
Subject: Re: [pkix] Use of th= e OSCP unknown response



Skickat fr=E5n min iPad

15 aug 2012 kl. 07:4= 5 skrev Stefan Santesson <stefan@aaa-sec.com>:

> Note: This question is not abou= t chaining OCSP. It is about what would be
> compliant with the current spec.
>
>
>
> > I'm having some exchange with members of CAB forum regarding their us= e of
> OCSP.
>
> They want to require OCSP responders bel= onging to compliant CAs to NOT
> return a "good" response unless they have a record of the certificate<= br>> being asked about.
>
> It seems to me that it would be = perfectly in line with current OCSP spec
> to return "unknown" in case= the CA has no record of the certificate being
> asked about.
>
> Current text from RFC 2560:
> &nbs= p;The "unknown" state indicates that the responder doesn't know about
>= ;  the certificate being requested.
>
>
>
> Does anyone have a different opinion?

:)

Yes. This is th= e perennial debate, since the early days of OCSP.

There are actually= two discussions. 1/ should we at all allow the issuance question to be answ= ered in the protocol 2/ if we do, how should it be expressed? There are good= arguments both ways regarding 1, but I feel we should, and doing that answe= r 2 just to put this dead horse to rest once and for all.

In my mind = the three possible responses are "good", "bad" and "don't know, ask someone = else if you really want to know". Granted, the wording of the "unknown" defi= nition is a bit vague, but it cannot be read as an affirmative response abou= t the non-existence of a certificate. The real problem is that "bad" is labe= led "revoked" in the document and defined only as such. The "good" definitio= n on the other hand foresees the issuance question:

 =  The "good" state indicates a positive response to the status inquiry.=
   At a minimum, this positive response indicates that the certif= icate
   is not revoked, but does not necessarily mean that the= certificate
   was ever issued or that the time at which the r= esponse was produced
   is within the certificate's validity interval. Response extens= ions
   may be used to convey additional information on asserti= ons made by
   the responder regarding the status of the certif= icate such as
   positive statement about issuance, validity, e= tc.

My position is that reading "unknown" as an assertion of= non-issuance is contrived. It is more reasonable to read it as "...the resp= onder doesn't know about [the status of] the certificate requested" (as in I= can't map the CertID to any CA, or I am temporarily offline with regards to= that CA). Looks very much more like an editing error than anything else.
The client can only do three thing as a result of an OCSP response: acc= ept the certificate, reject it, or try to get better information later or at= some other place. There is little point in having two "reject" responses, e= specially if it comes at the expense of the "try-somewhere-else-or-come-back= -later-if-you-have-time" response.

I propose that we resolve this by= defining the extension that the "good" definition talks about, and changing= the label of "revoked" to be "bad". I suggest that if you want the responde= r to answer the question about issuance, you use a single request extension = to signal that. And if you want to answer the question, you answer good if i= t is issued and not revoked or bad/revoked if it is non-issued with reason c= ode certificate hold and an invalidity date at the beginning of time; adding= a single response extension in both cases to show that you have considered = the issuance question. The exact syntax of the single request/response exten= sion can be discussed, but it potentially could include a hash of the certif= icate at hand.

This would leave us with three orthogonal = response states: "good"/"bad"/"don't-know" and clear out a lot of confusion.=

/Simon

> /Stefan
>
>
> ____________________________________= ___________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pk= ix
 --B_3427874052_18922405-- From stefan@aaa-sec.com Wed Aug 15 02:20:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1BB21F87A2 for ; Wed, 15 Aug 2012 02:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.023 X-Spam-Level: X-Spam-Status: No, score=-103.023 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-Zc-j4udaK5 for ; Wed, 15 Aug 2012 02:20:40 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id BDC7E21F8794 for ; Wed, 15 Aug 2012 02:20:40 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 287CB1DAD8D6 for ; Wed, 15 Aug 2012 11:20:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Xhpy_k_FYAI7 for ; Wed, 15 Aug 2012 11:20:38 +0200 (CEST) Received: from s328.loopia.se (new-s34.loopia.se [194.9.94.94]) by s87.loopia.se (Postfix) with ESMTP id DE8291DACE40 for ; Wed, 15 Aug 2012 11:20:37 +0200 (CEST) Received: (qmail 4899 invoked from network); 15 Aug 2012 09:20:37 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 15 Aug 2012 09:20:37 -0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Wed, 15 Aug 2012 11:20:34 +0200 From: Stefan Santesson To: Rob Stradling , Simon Tardell Message-ID: Thread-Topic: [pkix] Use of the OSCP unknown response In-Reply-To: <502B606C.40504@comodo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 09:20:41 -0000 I'm reluctant to rename these labels of OCSP. These labels are not UI components, they are simply labels used in the protocol. Changing labels in ASN.1 is problematic as ASN.1 often is compiled into code where the labels form variable names. Changing label names thus creates unnecessary problems for implementers. It is better then to clarify the labels if necessary. /Stefan On 12-08-15 10:40 AM, "Rob Stradling" wrote: >On 15/08/12 09:14, Simon Tardell wrote: > >> I propose that we resolve this by defining the extension that the "good" >> definition talks about > >http://tools.ietf.org/html/draft-hallambaker-ocspdigest > >> , and changing the label of "revoked" to be "bad". > >If a label change is permitted (in 2560bis), I'd prefer to see "good" >changed to "not revoked". > >-- >Rob Stradling >Senior Research & Development Scientist >COMODO - Creating Trust Online > From rob.stradling@comodo.com Wed Aug 15 02:46:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E72021F84F0 for ; Wed, 15 Aug 2012 02:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-OcCN6qTat8 for ; Wed, 15 Aug 2012 02:46:30 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id E628421F84EA for ; Wed, 15 Aug 2012 02:46:29 -0700 (PDT) Received: (qmail 23277 invoked from network); 15 Aug 2012 09:46:28 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 15 Aug 2012 09:46:28 -0000 Received: (qmail 15620 invoked by uid 1000); 15 Aug 2012 09:46:27 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 15 Aug 2012 10:46:27 +0100 Message-ID: <502B6F6E.5080707@comodo.com> Date: Wed, 15 Aug 2012 10:44:14 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 09:46:31 -0000 On 15/08/12 10:14, Stefan Santesson wrote: > Hi Simon, > > Your read more into my question than I asked (or proposed). > > I never asked/suggested that the unknown response should be interpreted > as a confirmation that the certificate was never issued. > The question was whether it would be conformant to send the "unknown" > response if the cert has never been issued. > > Do you see the difference? > > In the context of my question, the client would not know that the > certificate was never issued. It would simply know that the responder > don't know about the cert for any given reason you mention. > > Yes I agree we would need an extension to signal (if at all) an explicit > confirmation that the certificate was never issued. The question is > still what response that could be returned if that extension states that > the certificate was never issued. > > There are only three to choose from good, revoked and unknown. It seems > to me that "unknown" is the only reasonable alternative RFC2560 says: The "unknown" state indicates that the responder doesn't know about the certificate being requested. How could "unknown" possibly be the correct response if the responder _does know_ for certain that the "certificate being requested" was never issued? > as both "good" and "revoked" are clearly wrong. I agree that "revoked" is clearly wrong, since a certificate must first have been issued before it can be revoked. So IMHO, the "good" state would have to be used because "good...does not necessarily mean that the certificate was ever issued". (But since the CABForum have decided to disallow "good" for non-issued certs, I conclude that CABForum-compliant CAs simply cannot use a signed OCSP Response at all for non-issued certs. They'll have to use the unsigned "unauthorized" Response instead, as per the (extended) definition in RFC5019 Section 2.2.3). > /Stefan > > > From: Simon Tardell > > Date: Wednesday, 15 August, 2012 10:14 AM > To: Stefan Santesson > > Cc: pkix > > Subject: Re: [pkix] Use of the OSCP unknown response > > > > Skickat från min iPad > > 15 aug 2012 kl. 07:45 skrev Stefan Santesson >: > > > Note: This question is not about chaining OCSP. It is about what would be > > compliant with the current spec. > > > > > > > > > > I'm having some exchange with members of CAB forum regarding their use of > > OCSP. > > > > They want to require OCSP responders belonging to compliant CAs to NOT > > return a "good" response unless they have a record of the certificate > > being asked about. > > > > It seems to me that it would be perfectly in line with current OCSP spec > > to return "unknown" in case the CA has no record of the certificate being > > asked about. > > > > Current text from RFC 2560: > > The "unknown" state indicates that the responder doesn't know about > > the certificate being requested. > > > > > > > > Does anyone have a different opinion? > > :) > > Yes. This is the perennial debate, since the early days of OCSP. > > There are actually two discussions. 1/ should we at all allow the > issuance question to be answered in the protocol 2/ if we do, how > should it be expressed? There are good arguments both ways regarding > 1, but I feel we should, and doing that answer 2 just to put this > dead horse to rest once and for all. > > In my mind the three possible responses are "good", "bad" and "don't > know, ask someone else if you really want to know". Granted, the > wording of the "unknown" definition is a bit vague, but it cannot be > read as an affirmative response about the non-existence of a > certificate. The real problem is that "bad" is labeled "revoked" in > the document and defined only as such. The "good" definition on the > other hand foresees the issuance question: > > The "good" state indicates a positive response to the status > inquiry. > At a minimum, this positive response indicates that the > certificate > is not revoked, but does not necessarily mean that the > certificate > was ever issued or that the time at which the response was > produced > is within the certificate's validity interval. Response > extensions > may be used to convey additional information on assertions > made by > the responder regarding the status of the certificate such as > positive statement about issuance, validity, etc. > > > My position is that reading "unknown" as an assertion of > non-issuance is contrived. It is more reasonable to read it as > "...the responder doesn't know about [the status of] the certificate > requested" (as in I can't map the CertID to any CA, or I am > temporarily offline with regards to that CA). Looks very much more > like an editing error than anything else. > > The client can only do three thing as a result of an OCSP response: > accept the certificate, reject it, or try to get better information > later or at some other place. There is little point in having two > "reject" responses, especially if it comes at the expense of the > "try-somewhere-else-or-come-back-later-if-you-have-time" response. > > I propose that we resolve this by defining the extension that the > "good" definition talks about, and changing the label of "revoked" > to be "bad". I suggest that if you want the responder to answer the > question about issuance, you use a single request extension to > signal that. And if you want to answer the question, you answer good > if it is issued and not revoked or bad/revoked if it is non-issued > with reason code certificate hold and an invalidity date at the > beginning of time; adding a single response extension in both cases > to show that you have considered the issuance question. The exact > syntax of the single request/response extension can be discussed, > but it potentially could include a hash of the certificate at hand. > > This would leave us with three orthogonal response states: > "good"/"bad"/"don't-know" and clear out a lot of confusion. > > /Simon > > > /Stefan > > > > > > _______________________________________________ > > pkix mailing list > >pkix@ietf.org > >https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From simon@tardell.se Wed Aug 15 02:55:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775C821F875A for ; Wed, 15 Aug 2012 02:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z4WVpWQaKy4 for ; Wed, 15 Aug 2012 02:55:46 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A25F921F8738 for ; Wed, 15 Aug 2012 02:55:39 -0700 (PDT) Received: by lahm15 with SMTP id m15so761474lah.31 for ; Wed, 15 Aug 2012 02:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tardell.se; s=delta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=77FVv0kJ8WsC5LKgaZPov/ybgh6PUACRox8rc1mzolU=; b=hBsO45HWIMPwvmiVxhfKv9QfgGt3yENB6nZcJJ4swrS8wQDR67m8zboCfEMCdDiwB0 WnA55UyJqbqopKQnL+Bg8UHz4fpoSKBdUWdd9XUY5sMCcbqN50QuheaniFkHdVSpdIom 8g83l5ew8D4DVMiXzb11b9JOz3vIpSt6Apl3A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=77FVv0kJ8WsC5LKgaZPov/ybgh6PUACRox8rc1mzolU=; b=nbzX6gKk4WqoCEk4IkXcmhDTdcwoIw2FLWhei9CxXcVTgFJJVI8ZO6QRmSPUVXGGT0 UfanKbzf2vaOI82V81CPzm1tFgCC9304ubH5dLfFbBZtb3+YS00HTZvLv8heFw22wGje mwvgvnPsk4pOp42Q7725bhU5kRk3fKeqrXrOwfqNWHanqT4Riv7iZ4QRh+ubOEVip2o7 XDN66n17z8UTjKogt3Bd00pap8ZRBfMwm+aoAaAUel/XD62xEPndCGFvBnzYGxgMakas RmjbHnNZOWKQvCMzxF75jlVCWfaE2l2gyYpzV6Dis6ilAUI6rMRrLwkzw8d2qhmc1d1h CRPA== MIME-Version: 1.0 Received: by 10.112.85.35 with SMTP id e3mr9397129lbz.90.1345024538190; Wed, 15 Aug 2012 02:55:38 -0700 (PDT) Received: by 10.112.46.131 with HTTP; Wed, 15 Aug 2012 02:55:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Aug 2012 11:55:38 +0200 Message-ID: From: Simon Tardell To: Stefan Santesson Content-Type: multipart/alternative; boundary=bcaec555557cd022e704c74aed49 X-Gm-Message-State: ALoCoQlkp/NfNn56a45qoHGFZfmoaOF0LlMT/n01650d7A1QdgfY6q25o/OnaeLw3feSRFXldhSQ Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 09:55:47 -0000 --bcaec555557cd022e704c74aed49 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 15, 2012 at 11:14 AM, Stefan Santesson wrot= e: > Hi Simon, > > Your read more into my question than I asked (or proposed). > > I never asked/suggested that the unknown response should be interpreted a= s > a confirmation that the certificate was never issued. > The question was whether it would be conformant to send the "unknown" > response if the cert has never been issued. > > Do you see the difference? > > In the context of my question, the client would not know that the > certificate was never issued. It would simply know that the responder don= 't > know about the cert for any given reason you mention. > Yes, but what do you want to achieve, as a responder? If you want to make the client reject the certificate you really have to answer "revoked". If you answer "unknown", a lot of clients will have the option to fall back to some other source of revocation information, be it CRLs or another OCSP responder. And then you have a security problem. Better to answer something safe from the responder. Also, I think it wouldn't be compliant to answer "unknown". If you know the certificate hasn't been issued, you know about the certificate (viz. the property that it wasn't issued), which clearly contradicts the wording in the RFC. > Yes I agree we would need an extension to signal (if at all) an explicit > confirmation that the certificate was never issued. The question is still > what response that could be returned if that extension states that the > certificate was never issued. > > There are only three to choose from good, revoked and unknown. It seems t= o > me that "unknown" is the only reasonable alternative as both "good" and > "revoked" are clearly wrong. > I don't agree that using revoked would be clearly wrong. What is wrong is the current wording of "revoked", which is not aligned with the wording of "good". If you clarify/correct the wording of the "revoked" definition according to my suggestion you would not change anything for clients who don't understand the extension, and you would also preserve the possibility of redundancy at the protocol level for PKIs that need it (and while it might be use case of limited application there definitely are those out there that require it). The extension would of course only be needed if the client cared about why he shouldn't accept the certificate. Also, I think the use of certificate-hold to signal not-issued aligns quite well. Both are conditions that can change in the future so that the certificate becomes valid for use. So while it could seem odd that a certificate that hasn't been issued is already a kind of revoked I think that is only about labels not about actual semantics. I think we should write in the RFC what the client is expected to do in each case: "good" it MAY accept the certificate "revoked" it SHOULD reject the certificate "unknown" it may try some other revocation source (as defined by whatever policy you have), or try again later if it has the possibility, failing that it SHOULD reject the certificate /Simon > > /Stefan > > > From: Simon Tardell > Date: Wednesday, 15 August, 2012 10:14 AM > To: Stefan Santesson > Cc: pkix > Subject: Re: [pkix] Use of the OSCP unknown response > > > > Skickat fr=E5n min iPad > > 15 aug 2012 kl. 07:45 skrev Stefan Santesson : > > > Note: This question is not about chaining OCSP. It is about what would = be > > compliant with the current spec. > > > > > > > > > > I'm having some exchange with members of CAB forum regarding their use = of > > OCSP. > > > > They want to require OCSP responders belonging to compliant CAs to NOT > > return a "good" response unless they have a record of the certificate > > being asked about. > > > > It seems to me that it would be perfectly in line with current OCSP spe= c > > to return "unknown" in case the CA has no record of the certificate bei= ng > > asked about. > > > > Current text from RFC 2560: > > The "unknown" state indicates that the responder doesn't know about > > the certificate being requested. > > > > > > > > Does anyone have a different opinion? > > :) > > Yes. This is the perennial debate, since the early days of OCSP. > > There are actually two discussions. 1/ should we at all allow the issuanc= e > question to be answered in the protocol 2/ if we do, how should it be > expressed? There are good arguments both ways regarding 1, but I feel we > should, and doing that answer 2 just to put this dead horse to rest once > and for all. > > In my mind the three possible responses are "good", "bad" and "don't know= , > ask someone else if you really want to know". Granted, the wording of the > "unknown" definition is a bit vague, but it cannot be read as an > affirmative response about the non-existence of a certificate. The real > problem is that "bad" is labeled "revoked" in the document and defined on= ly > as such. The "good" definition on the other hand foresees the issuance > question: > > The "good" state indicates a positive response to the status inquiry. >> At a minimum, this positive response indicates that the certificate >> is not revoked, but does not necessarily mean that the certificate >> was ever issued or that the time at which the response was produced >> is within the certificate's validity interval. Response extensions >> may be used to convey additional information on assertions made by >> the responder regarding the status of the certificate such as >> positive statement about issuance, validity, etc. > > > My position is that reading "unknown" as an assertion of non-issuance is > contrived. It is more reasonable to read it as "...the responder doesn't > know about [the status of] the certificate requested" (as in I can't map > the CertID to any CA, or I am temporarily offline with regards to that CA= ). > Looks very much more like an editing error than anything else. > > The client can only do three thing as a result of an OCSP response: accep= t > the certificate, reject it, or try to get better information later or at > some other place. There is little point in having two "reject" responses, > especially if it comes at the expense of the > "try-somewhere-else-or-come-back-later-if-you-have-time" response. > > I propose that we resolve this by defining the extension that the "good" > definition talks about, and changing the label of "revoked" to be "bad". = I > suggest that if you want the responder to answer the question about > issuance, you use a single request extension to signal that. And if you > want to answer the question, you answer good if it is issued and not > revoked or bad/revoked if it is non-issued with reason code certificate > hold and an invalidity date at the beginning of time; adding a single > response extension in both cases to show that you have considered the > issuance question. The exact syntax of the single request/response > extension can be discussed, but it potentially could include a hash of th= e > certificate at hand. > > This would leave us with three orthogonal response states: > "good"/"bad"/"don't-know" and clear out a lot of confusion. > > /Simon > > > /Stefan > > > > > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > > --bcaec555557cd022e704c74aed49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 15, 2012 at 11:14 AM, Stefan= Santesson <stefan@aaa-sec.com> wrote:
Hi Simon,

Your read more into my quest= ion than I asked (or proposed).

I never asked/sugg= ested that the unknown response should be interpreted as a confirmation tha= t the certificate was never issued.
The question was whether it would be conformant to send the "unkn= own" response if the cert has never been issued.

<= div>Do you see the difference?

In the context of m= y question, the client would not know that the certificate was never issued= . It would simply know that the responder don't know about the cert for= any given reason you mention.

Yes, but what do you want to achieve= , as a responder? If you want to make the client reject the certificate you= really have to answer "revoked". If you answer "unknown&quo= t;, a lot of clients will have the option to fall back to some other source= of revocation information, be it CRLs or another OCSP responder. And then = you have a security problem. Better to answer something safe from the respo= nder.=A0

Also, I think it wouldn't be compliant to answer &q= uot;unknown". If you know the certificate hasn't been issued, you = know about the certificate (viz. the property that it wasn't issued), w= hich clearly contradicts the wording in the RFC.
=A0
Yes I agree we wou= ld need an extension to signal (if at all) an explicit confirmation that th= e certificate was never issued. The question is still what response that co= uld be returned if that extension states that the certificate was never iss= ued.

=A0
There are only three to choose from good, revoked and unkno= wn. It seems to me that "unknown" is the only reasonable alternat= ive as both "good" and "revoked" are clearly wrong.

I don't agree that using revoked= would be clearly wrong. What is wrong is the current wording of "revo= ked", which is not aligned with the wording of "good". If yo= u clarify/correct the wording of the "revoked" definition accordi= ng to my suggestion you would not change anything for clients who don't= understand the extension, and you would also preserve the possibility of r= edundancy at the protocol level for PKIs that need it (and while it might b= e use case of limited application there definitely are those out there that= require it).=A0

The extension would of course only be needed if the cli= ent cared about why he shouldn't accept the certificate.=A0
<= br>
Also, I think the use of certificate-hold to signal not-issue= d aligns quite well. Both are conditions that can change in the future so t= hat the certificate becomes valid for use. So while it could seem odd that = a certificate that hasn't been issued is already a kind of revoked I th= ink that is only about labels not about actual semantics.=A0

I think we should write in the RFC what the client is e= xpected to do in each case:
"good" it MAY accept the ce= rtificate
"revoked" it SHOULD reject the certificate
"unknown" it may try some =A0other revocation source (as def= ined by whatever policy you have), or try again later if it has the possibi= lity, failing that it SHOULD reject the certificate

/Simon
=A0

/Stefan


From: Simon Tardell <simon@tardell.se>
Date: Wednesday, 15 August, 2012 10:1= 4 AM
To: Stefan Santesson <stefan@aaa-sec.com>=
Cc: pkix <pkix@ietf.org>
Subject: Re: [pkix] Use of the OSC= P unknown response


Skickat fr=E5n min iPad

15 aug 2012 kl. 07:45 skrev Stefan Santesson= <stefan@aaa-sec= .com>:

> Note: This question is not about chaining OCSP. I= t is about what would be
> compliant with the current spec.
>
>
>
> > I'm having some exchange with members of CAB forum regarding the= ir use of
> OCSP.
>
> They want to require OCSP responde= rs belonging to compliant CAs to NOT
> return a "good" response unless they have a record of the ce= rtificate
> being asked about.
>
> It seems to me that i= t would be perfectly in line with current OCSP spec
> to return "= ;unknown" in case the CA has no record of the certificate being
> asked about.
>
> Current text from RFC 2560:
> =A0T= he "unknown" state indicates that the responder doesn't know = about
> =A0the certificate being requested.
>
>
>=
> Does anyone have a different opinion?

:)

Yes. This is th= e perennial debate, since the early days of OCSP.

There are actuall= y two discussions. 1/ should we at all allow the issuance question to be an= swered in the protocol 2/ if we do, how should it be expressed? There are g= ood arguments both ways regarding 1, but I feel we should, and doing that a= nswer 2 just to put this dead horse to rest once and for all.

In my mind the three possible responses are "good", "bad= " and "don't know, ask someone else if you really want to kno= w". Granted, the wording of the "unknown" definition is a bi= t vague, but it cannot be read as an affirmative response about the non-exi= stence of a certificate. The real problem is that "bad" is labele= d "revoked" in the document and defined only as such. The "g= ood" definition on the other hand foresees the issuance question:

=A0 =A0The "good" state indicates a positive= response to the status inquiry.
=A0 =A0At a minimum, this positive response indicates that the certificate<= br>=A0 =A0is not revoked, but does not necessarily mean that the certificat= e
=A0 =A0was ever issued or that the time at which the response was prod= uced
=A0 =A0is within the certificate's validity interval. Response extensio= ns
=A0 =A0may be used to convey additional information on assertions mad= e by
=A0 =A0the responder regarding the status of the certificate such a= s
=A0 =A0positive statement about issuance, validity, etc.

My position is that reading "unknown" as an assertion of non-= issuance is contrived. It is more reasonable to read it as "...the res= ponder doesn't know about [the status of] the certificate requested&quo= t; (as in I can't map the CertID to any CA, or I am temporarily offline= with regards to that CA). Looks very much more like an editing error than = anything else.

The client can only do three thing as a result of an OCSP response: acc= ept the certificate, reject it, or try to get better information later or a= t some other place. There is little point in having two "reject" = responses, especially if it comes at the expense of the "try-somewhere= -else-or-come-back-later-if-you-have-time" response.

I propose that we resolve this by defining the extension that the "= ;good" definition talks about, and changing the label of "revoked= " to be "bad". I suggest that if you want the responder to a= nswer the question about issuance, you use a single request extension to si= gnal that. And if you want to answer the question, you answer good if it is= issued and not revoked or bad/revoked if it is non-issued with reason code= certificate hold and an invalidity date at the beginning of time; adding a= single response extension in both cases to show that you have considered t= he issuance question. The exact syntax of the single request/response exten= sion can be discussed, but it potentially could include a hash of the certi= ficate at hand.

This would leave us with three orthogonal response states: &= quot;good"/"bad"/"don't-know" and clear out a = lot of confusion.

/Simon

> /Stefan
>
>
> ____________________________________= ___________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/= listinfo/pkix

--bcaec555557cd022e704c74aed49-- From stefan@aaa-sec.com Wed Aug 15 03:03:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3856021F86FD for ; Wed, 15 Aug 2012 03:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.034 X-Spam-Level: X-Spam-Status: No, score=-103.034 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q33EzhPAixcM for ; Wed, 15 Aug 2012 03:03:55 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A119721F86FA for ; Wed, 15 Aug 2012 03:03:55 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id D0A9A1DAA951 for ; Wed, 15 Aug 2012 12:03:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Z-NuW90oRFc7 for ; Wed, 15 Aug 2012 12:03:37 +0200 (CEST) Received: from s331.loopia.se (new-s34.loopia.se [194.9.94.94]) by s87.loopia.se (Postfix) with ESMTP id 94BCB1D31B32 for ; Wed, 15 Aug 2012 12:03:37 +0200 (CEST) Received: (qmail 25327 invoked from network); 15 Aug 2012 10:03:37 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 15 Aug 2012 10:03:37 -0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Wed, 15 Aug 2012 12:03:33 +0200 From: Stefan Santesson To: Rob Stradling Message-ID: Thread-Topic: [pkix] Use of the OSCP unknown response In-Reply-To: <502B6F6E.5080707@comodo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 10:03:56 -0000 On 12-08-15 11:44 AM, "Rob Stradling" wrote: >How could "unknown" possibly be the correct response if the responder >_does know_ for certain that the "certificate being requested" was never >issued? >From an OCSP responder's perspective this sounds quite logical to me. If the OCSP responder has been handed a positive list, and the requested cert is not on that lists, then the OCSP responder simply "does not know" about that certificate. In theory, that certificate may have been issued but has not yet made it to the positive list. Perhaps that certificate has been issued ahead of it's validity period and will not make it to the positive list until it does. An interesting question is what would happen if an "unknown" response was sent. /Stefan From stefan@aaa-sec.com Wed Aug 15 03:09:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6C221F8734 for ; Wed, 15 Aug 2012 03:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-DeiXhSly65 for ; Wed, 15 Aug 2012 03:09:33 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAAB21F87AB for ; Wed, 15 Aug 2012 03:09:32 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 8627C1DAE163 for ; Wed, 15 Aug 2012 12:06:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Sa02dW_hz9Ci for ; Wed, 15 Aug 2012 12:06:53 +0200 (CEST) Received: from s328.loopia.se (new-s34.loopia.se [194.9.94.94]) by s87.loopia.se (Postfix) with ESMTP id 6290D1DAE15F for ; Wed, 15 Aug 2012 12:06:53 +0200 (CEST) Received: (qmail 49337 invoked from network); 15 Aug 2012 10:06:53 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 15 Aug 2012 10:06:53 -0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Wed, 15 Aug 2012 12:06:51 +0200 From: Stefan Santesson To: Simon Tardell Message-ID: Thread-Topic: [pkix] Use of the OSCP unknown response In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3427877213_19086380" Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 10:09:35 -0000 > 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. --B_3427877213_19086380 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Simon, I thin you have a point here. I could definitely see the security advantage of declaring the case when th= e CA knows the certificate to never have been issued to reply "revoked". I guess this could be clarified in the text of 2560bis. Even though I still see some cases where "unknown" could be valid (see previous mail), I do think you are right in the case when the cert is known to never have been issued. /Stefan From: Simon Tardell Date: Wednesday, 15 August, 2012 11:55 AM To: Stefan Santesson Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response >=20 >=20 > On Wed, Aug 15, 2012 at 11:14 AM, Stefan Santesson w= rote: >> Hi Simon, >>=20 >> Your read more into my question than I asked (or proposed). >>=20 >> I never asked/suggested that the unknown response should be interpreted = as a >> confirmation that the certificate was never issued. >> The question was whether it would be conformant to send the "unknown" >> response if the cert has never been issued. >>=20 >> Do you see the difference? >>=20 >> In the context of my question, the client would not know that the certif= icate >> was never issued. It would simply know that the responder don't know abo= ut >> the cert for any given reason you mention. >=20 > Yes, but what do you want to achieve, as a responder? If you want to make= the > client reject the certificate you really have to answer "revoked". If you > answer "unknown", a lot of clients will have the option to fall back to s= ome > other source of revocation information, be it CRLs or another OCSP respon= der. > And then you have a security problem. Better to answer something safe fro= m the > responder.=20 >=20 > Also, I think it wouldn't be compliant to answer "unknown". If you know t= he > certificate hasn't been issued, you know about the certificate (viz. the > property that it wasn't issued), which clearly contradicts the wording in= the > RFC. > =20 >> Yes I agree we would need an extension to signal (if at all) an explicit >> confirmation that the certificate was never issued. The question is stil= l >> what response that could be returned if that extension states that the >> certificate was never issued. >=20 > =20 >> There are only three to choose from good, revoked and unknown. It seems = to me >> that "unknown" is the only reasonable alternative as both "good" and >> "revoked" are clearly wrong. >=20 > I don't agree that using revoked would be clearly wrong. What is wrong is= the > current wording of "revoked", which is not aligned with the wording of "g= ood". > If you clarify/correct the wording of the "revoked" definition according = to my > suggestion you would not change anything for clients who don't understand= the > extension, and you would also preserve the possibility of redundancy at t= he > protocol level for PKIs that need it (and while it might be use case of > limited application there definitely are those out there that require it)= . >=20 > The extension would of course only be needed if the client cared about wh= y he > shouldn't accept the certificate. >=20 > Also, I think the use of certificate-hold to signal not-issued aligns qui= te > well. Both are conditions that can change in the future so that the > certificate becomes valid for use. So while it could seem odd that a > certificate that hasn't been issued is already a kind of revoked I think = that > is only about labels not about actual semantics. >=20 > I think we should write in the RFC what the client is expected to do in e= ach > case: > "good" it MAY accept the certificate > "revoked" it SHOULD reject the certificate > "unknown" it may try some other revocation source (as defined by whateve= r > policy you have), or try again later if it has the possibility, failing t= hat > it SHOULD reject the certificate >=20 > /Simon > =20 >>=20 >> /Stefan >>=20 >>=20 >> From: Simon Tardell >> Date: Wednesday, 15 August, 2012 10:14 AM >> To: Stefan Santesson >> Cc: pkix >> Subject: Re: [pkix] Use of the OSCP unknown response >>=20 >>>=20 >>>=20 >>> Skickat fr=E5n min iPad >>>=20 >>> 15 aug 2012 kl. 07:45 skrev Stefan Santesson : >>>=20 >>>> > Note: This question is not about chaining OCSP. It is about what wou= ld be >>>> > compliant with the current spec. >>>> >=20 >>>> >=20 >>>> >=20 >>>> >=20 >>>> > I'm having some exchange with members of CAB forum regarding their u= se of >>>> > OCSP. >>>> >=20 >>>> > They want to require OCSP responders belonging to compliant CAs to N= OT >>>> > return a "good" response unless they have a record of the certificat= e >>>> > being asked about. >>>> >=20 >>>> > It seems to me that it would be perfectly in line with current OCSP = spec >>>> > to return "unknown" in case the CA has no record of the certificate = being >>>> > asked about. >>>> >=20 >>>> > Current text from RFC 2560: >>>> > The "unknown" state indicates that the responder doesn't know about >>>> > the certificate being requested. >>>> >=20 >>>> >=20 >>>> >=20 >>>> > Does anyone have a different opinion? >>>=20 >>> :) >>>=20 >>> Yes. This is the perennial debate, since the early days of OCSP. >>>=20 >>> There are actually two discussions. 1/ should we at all allow the issua= nce >>> question to be answered in the protocol 2/ if we do, how should it be >>> expressed? There are good arguments both ways regarding 1, but I feel w= e >>> should, and doing that answer 2 just to put this dead horse to rest onc= e and >>> for all. >>>=20 >>> In my mind the three possible responses are "good", "bad" and "don't kn= ow, >>> ask someone else if you really want to know". Granted, the wording of t= he >>> "unknown" definition is a bit vague, but it cannot be read as an affirm= ative >>> response about the non-existence of a certificate. The real problem is = that >>> "bad" is labeled "revoked" in the document and defined only as such. Th= e >>> "good" definition on the other hand foresees the issuance question: >>>=20 >>>> The "good" state indicates a positive response to the status inquir= y. >>>> At a minimum, this positive response indicates that the certificate >>>> is not revoked, but does not necessarily mean that the certificate >>>> was ever issued or that the time at which the response was produced >>>> is within the certificate's validity interval. Response extensions >>>> may be used to convey additional information on assertions made by >>>> the responder regarding the status of the certificate such as >>>> positive statement about issuance, validity, etc. >>>=20 >>> My position is that reading "unknown" as an assertion of non-issuance i= s >>> contrived. It is more reasonable to read it as "...the responder doesn'= t >>> know about [the status of] the certificate requested" (as in I can't ma= p the >>> CertID to any CA, or I am temporarily offline with regards to that CA). >>> Looks very much more like an editing error than anything else. >>>=20 >>> The client can only do three thing as a result of an OCSP response: acc= ept >>> the certificate, reject it, or try to get better information later or a= t >>> some other place. There is little point in having two "reject" response= s, >>> especially if it comes at the expense of the >>> "try-somewhere-else-or-come-back-later-if-you-have-time" response. >>>=20 >>> I propose that we resolve this by defining the extension that the "good= " >>> definition talks about, and changing the label of "revoked" to be "bad"= . I >>> suggest that if you want the responder to answer the question about >>> issuance, you use a single request extension to signal that. And if you= want >>> to answer the question, you answer good if it is issued and not revoked= or >>> bad/revoked if it is non-issued with reason code certificate hold and a= n >>> invalidity date at the beginning of time; adding a single response exte= nsion >>> in both cases to show that you have considered the issuance question. T= he >>> exact syntax of the single request/response extension can be discussed,= but >>> it potentially could include a hash of the certificate at hand. >>>=20 >>> This would leave us with three orthogonal response states: >>> "good"/"bad"/"don't-know" and clear out a lot of confusion. >>>=20 >>> /Simon >>>=20 >>>> > /Stefan >>>> >=20 >>>> >=20 >>>> > _______________________________________________ >>>> > pkix mailing list >>>> > pkix@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/pkix >=20 --B_3427877213_19086380 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Simon,

<= div>I thin you have a point here.
I could definitely see the secur= ity advantage of declaring the case when the CA knows the certificate to nev= er have been issued to reply "revoked".

I guess thi= s could be clarified in the text of 2560bis.

Even t= hough I still see some cases where "unknown" could be valid (see previous ma= il), I do think you are right in the case when the cert is known to never ha= ve been issued.

/Stefan

From: Simon Tardell <simon@tardell.se>
Date: = Wednesday, 15 August, 2012 11:55 AM
To: Stefan Santesson <stefa= n@aaa-sec.com>
Cc: pkix <= ;pkix@ietf.org>
Subject: Re: [pkix] Use of the OSCP unknown response
=



=
On Wed, Aug 15, 2012 at 11:14 AM, Stefan Santesson = <stef= an@aaa-sec.com> wrote:
H= i Simon,

Your read more into my question than I ask= ed (or proposed).

I never asked/suggested that the = unknown response should be interpreted as a confirmation that the certificat= e was never issued.
The question was whether it would be conforman= t to send the "unknown" response if the cert has never been issued.

Do you see the difference?

In the = context of my question, the client would not know that the certificate was n= ever issued. It would simply know that the responder don't know about the ce= rt for any given reason you mention.

=
Yes, but what do you want to achieve, as a responder? If you want to ma= ke the client reject the certificate you really have to answer "revoked". If= you answer "unknown", a lot of clients will have the option to fall back to= some other source of revocation information, be it CRLs or another OCSP res= ponder. And then you have a security problem. Better to answer something saf= e from the responder. 

Also, I think it wouldn= 't be compliant to answer "unknown". If you know the certificate hasn't been= issued, you know about the certificate (viz. the property that it wasn't is= sued), which clearly contradicts the wording in the RFC.
 
Yes I agree we would need an extension= to signal (if at all) an explicit confirmation that the certificate was nev= er issued. The question is still what response that could be returned if tha= t extension states that the certificate was never issued.

 
There are only three to choose from good, revoked and unknown. It se= ems to me that "unknown" is the only reasonable alternative as both "good" a= nd "revoked" are clearly wrong.

= I don't agree that using revoked would be clearly wrong. What is wrong is th= e current wording of "revoked", which is not aligned with the wording of "go= od". If you clarify/correct the wording of the "revoked" definition accordin= g to my suggestion you would not change anything for clients who don't under= stand the extension, and you would also preserve the possibility of redundan= cy at the protocol level for PKIs that need it (and while it might be use ca= se of limited application there definitely are those out there that require = it). 

The extension would of course only be ne= eded if the client cared about why he shouldn't accept the certificate. = ;

Also, I think the use of certificate-hold to sign= al not-issued aligns quite well. Both are conditions that can change in the = future so that the certificate becomes valid for use. So while it could seem= odd that a certificate that hasn't been issued is already a kind of revoked= I think that is only about labels not about actual semantics. 

I think we should write in the RFC what the client is expe= cted to do in each case:
"good" it MAY accept the certificate
"revoked" it SHOULD reject the certificate
"unknown" it may = try some  other revocation source (as defined by whatever policy you ha= ve), or try again later if it has the possibility, failing that it SHOULD re= ject the certificate

/Simon
 

<= div>/Stefan


From: Simon Tardell <simon@tardell.se>
Date: Wednesday, 15 August, 2012 10:14 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: pkix <pkix@ietf.org>
Subject: Re= : [pkix] Use of the OSCP unknown response



Skickat fr=E5n min iPad

15 aug 2012 kl. 07:45 skrev Stefan Santesson &= lt;stefan@aaa-sec.com>:

> Note: This question is not about chaining OCSP. It is abo= ut what would be
> compliant with the current spec.
>
>
>
> > I'm having some exchange with members of CAB forum regarding their us= e of
> OCSP.
>
> They want to require OCSP responders bel= onging to compliant CAs to NOT
> return a "good" response unless they have a record of the certificate<= br>> being asked about.
>
> It seems to me that it would be = perfectly in line with current OCSP spec
> to return "unknown" in case= the CA has no record of the certificate being
> asked about.
>
> Current text from RFC 2560:
> &nbs= p;The "unknown" state indicates that the responder doesn't know about
>= ;  the certificate being requested.
>
>
>
> Does anyone have a different opinion?

:)

Yes. This is th= e perennial debate, since the early days of OCSP.

There are actually= two discussions. 1/ should we at all allow the issuance question to be answ= ered in the protocol 2/ if we do, how should it be expressed? There are good= arguments both ways regarding 1, but I feel we should, and doing that answe= r 2 just to put this dead horse to rest once and for all.

In my mind = the three possible responses are "good", "bad" and "don't know, ask someone = else if you really want to know". Granted, the wording of the "unknown" defi= nition is a bit vague, but it cannot be read as an affirmative response abou= t the non-existence of a certificate. The real problem is that "bad" is labe= led "revoked" in the document and defined only as such. The "good" definitio= n on the other hand foresees the issuance question:

 =  The "good" state indicates a positive response to the status inquiry.=
   At a minimum, this positive response indicates that the certif= icate
   is not revoked, but does not necessarily mean that the= certificate
   was ever issued or that the time at which the r= esponse was produced
   is within the certificate's validity interval. Response extens= ions
   may be used to convey additional information on asserti= ons made by
   the responder regarding the status of the certif= icate such as
   positive statement about issuance, validity, e= tc.

My position is that reading "unknown" as an assertion of= non-issuance is contrived. It is more reasonable to read it as "...the resp= onder doesn't know about [the status of] the certificate requested" (as in I= can't map the CertID to any CA, or I am temporarily offline with regards to= that CA). Looks very much more like an editing error than anything else.
The client can only do three thing as a result of an OCSP response: acc= ept the certificate, reject it, or try to get better information later or at= some other place. There is little point in having two "reject" responses, e= specially if it comes at the expense of the "try-somewhere-else-or-come-back= -later-if-you-have-time" response.

I propose that we resolve this by= defining the extension that the "good" definition talks about, and changing= the label of "revoked" to be "bad". I suggest that if you want the responde= r to answer the question about issuance, you use a single request extension = to signal that. And if you want to answer the question, you answer good if i= t is issued and not revoked or bad/revoked if it is non-issued with reason c= ode certificate hold and an invalidity date at the beginning of time; adding= a single response extension in both cases to show that you have considered = the issuance question. The exact syntax of the single request/response exten= sion can be discussed, but it potentially could include a hash of the certif= icate at hand.

<= br> --B_3427877213_19086380-- From kent@bbn.com Wed Aug 15 07:16:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4344F21F875D for ; Wed, 15 Aug 2012 07:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUOegWZPTuoQ for ; Wed, 15 Aug 2012 07:16:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2432221F876C for ; Wed, 15 Aug 2012 07:16:52 -0700 (PDT) Received: from dhcp89-089-055.bbn.com ([128.89.89.55]:51736) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T1eOj-000HKm-IN; Wed, 15 Aug 2012 10:16:37 -0400 Message-ID: <502BAF45.3010402@bbn.com> Date: Wed, 15 Aug 2012 10:16:37 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: denis.pinkas@bull.net References: <502A831F.9060503@bbn.com> <502AC5E2.3000801@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080600090907030606090706" Cc: pkix Subject: Re: [pkix] 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 14:16:53 -0000 This is a multi-part message in MIME format. --------------080600090907030606090706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/15/12 3:17 AM, denis.pinkas@bull.net wrote: > For of all, thank you Henry for your posting. > > Steve, do you mean that it is possible to object when the chairs are > proposing a straw poll ? > I was not thinking it was ever possible, so I did not objected. you could object, but the straw poll would take place anyway. > Steve, you said: > > "Also, during the course of the poll, there were several "essay" > responses, none of which suggested that course of action". > > This is not quite true. On August 6, I wrote to the list: > > "I hope to be able to deliver such a new version within two > weeks from now. > > I plan to add explanations: > > - for OCSP clients when they build a request, > - for OCSP clients when they verify a response. > (...) > > I plan to work from version -05 which is not "good enough", but > much better than version -04 with all its annexes." > > Two weeks from August 6 means August 20. My comment was in tended to say that none of the essay responses said that someone wanted to join you in preparing a different submission, which is my interpretation of the essence of Henry's question, > On August 10, the co-chairs privately received an intermediate copy of > the draft, so they could start > to build their own opinion about the improvements made, but I have > received no private response from > the co-chairs yet at this time. I did not reply since: - I don't work on Fridays and thus did not see your message until Monday. - I tallied the straw poll responses and it was clear that option A was the winner, by a large margin. > The question for me, at the time being, is whether I can post the drat > as : > > draft-ietf-pkix-rfc2560bis-06 no, you cannot post this as -06. > or whether I should post it as : > > draft-ietf-pinkas-rfc2560bis-00 you can post an individual submission. Steve --------------080600090907030606090706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 8/15/12 3:17 AM, denis.pinkas@bull.net wrote:
For of all, thank you Henry for your posting.

Steve, do you mean that it is possible to object when the chairs are proposing a straw poll ?
I was not thinking it was ever possible, so I did not objected.
you could object, but the straw poll would take place anyway.
Steve, you said:

"Also, during the course of the poll, there were several "essay"
responses, none of which suggested that course of action".

This is not quite true. On August 6, I wrote to the list:

        "I hope to be able to deliver such a new version within two weeks from now.

        I plan to add explanations:
                       - for OCSP clients when they build a request,
                 - for OCSP clients when they verify a response.
        (...)

        I plan to work from version -05 which is not "good enough", but
       much better than version -04 with all its annexes."

Two weeks from August 6 means August 20.
My comment was in tended to say that none of the essay responses said that
someone wanted to join you in preparing a different submission, which is my
interpretation of the essence of Henry's question,
On August 10, the co-chairs privately received an intermediate copy of the draft, so they could start
to build their own opinion about the improvements made, but I have received no private response from
the co-chairs yet at this time.
I did not reply since:
    - I don't work on Fridays and thus did not see your message until Monday.
    - I tallied the straw poll responses and it was clear
      that option A was the winner, by a large margin.
The question for me, at the time being, is whether I can post the drat as :

      draft-ietf-pkix-rfc2560bis-06
no, you cannot post this as -06.
or whether I should post it as :

      draft-ietf-pinkas-rfc2560bis-00
you can post an individual submission.

Steve
--------------080600090907030606090706-- From ben@digicert.com Wed Aug 15 08:26:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A8221F8671 for ; Wed, 15 Aug 2012 08:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtEOmquujFjC for ; Wed, 15 Aug 2012 08:26:14 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id BE50121F8622 for ; Wed, 15 Aug 2012 08:26:13 -0700 (PDT) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 4F3602E069; Wed, 15 Aug 2012 09:26:13 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1345044373; bh=ee0WJklcgOSyJzd96ULW21F63Iv3FQKr/ywWgTRT/jI=; h=Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date: Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YrSOGPT9Pa8TAzFe4IPory0EZ/se0VxMdDrYVbEarooF9MjclIjmVu4dV633h8VAX unPnp9mw4BI4sPaIUESli3IjjsgKb63PcHDZdTR7xQmA103O/GXAZujwZjKh5k3gdt Nk068wEJfcPVEcrVG4DXwDH/8YZmDmMAUMfVYe5c= From: "Ben Wilson" To: "'Rob Stradling'" , "'Stefan Santesson'" References: <502B6F6E.5080707@comodo.com> In-Reply-To: <502B6F6E.5080707@comodo.com> Date: Wed, 15 Aug 2012 09:26:10 -0600 Organization: DigiCert Message-ID: <007501cd7afa$4cb51180$e61f3480$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQL95eTFyed08iFwZ1Gq5OzMuWnA/wGb5m2OlO1G7XA= Content-Language: en-us Cc: 'pkix' Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 15:26:15 -0000 I agree with Rob with regard to an unsigned "unauthorized" response. = If certificate status is indeed unknown, then a signed "unknown" seems appropriate (but illogical where a CA should know whether the = certificate was issued -- it should not say "unknown" if it knows the certificate = was not issued). A delegated OCSP responder could respond "unknown". Otherwise, saying "unknown" would be a lie. I am very opposed to = responding "good" if there is no record of issuance, that is a lie, too. There are legal liability issues with misrepresenting the truth -- fraud, = negligent misrepresentation, etc. The fact that it is a technical standard should = not be used as an excuse when the response has legal implications - (ala Lessig's book "Code"). If extensions in this area are needed, then = they should be for the "unknown" and "unauthorized" responses. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Rob Stradling Sent: Wednesday, August 15, 2012 3:44 AM To: Stefan Santesson Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response On 15/08/12 10:14, Stefan Santesson wrote: > Hi Simon, > > Your read more into my question than I asked (or proposed). > > I never asked/suggested that the unknown response should be=20 > interpreted as a confirmation that the certificate was never issued. > The question was whether it would be conformant to send the "unknown" > response if the cert has never been issued. > > Do you see the difference? > > In the context of my question, the client would not know that the=20 > certificate was never issued. It would simply know that the responder=20 > don't know about the cert for any given reason you mention. > > Yes I agree we would need an extension to signal (if at all) an=20 > explicit confirmation that the certificate was never issued. The=20 > question is still what response that could be returned if that=20 > extension states that the certificate was never issued. > > There are only three to choose from good, revoked and unknown. It=20 > seems to me that "unknown" is the only reasonable alternative RFC2560 says: The "unknown" state indicates that the responder doesn't know about the certificate being requested. How could "unknown" possibly be the correct response if the responder = _does know_ for certain that the "certificate being requested" was never = issued? > as both "good" and "revoked" are clearly wrong. I agree that "revoked" is clearly wrong, since a certificate must first = have been issued before it can be revoked. So IMHO, the "good" state would have to be used because "good...does not necessarily mean that the certificate was ever issued". (But since the CABForum have decided to disallow "good" for non-issued certs, I conclude that CABForum-compliant CAs simply cannot use a signed OCSP Response at all for non-issued certs. They'll have to use the = unsigned "unauthorized" Response instead, as per the (extended) definition in = RFC5019 Section 2.2.3). > /Stefan > > > From: Simon Tardell > > Date: Wednesday, 15 August, 2012 10:14 AM > To: Stefan Santesson > > Cc: pkix > > Subject: Re: [pkix] Use of the OSCP unknown response > > > > Skickat fr=E5n min iPad > > 15 aug 2012 kl. 07:45 skrev Stefan Santesson >: > > > Note: This question is not about chaining OCSP. It is about what would be > > compliant with the current spec. > > > > > > > > > > I'm having some exchange with members of CAB forum regarding = their use of > > OCSP. > > > > They want to require OCSP responders belonging to compliant CAs = to NOT > > return a "good" response unless they have a record of the certificate > > being asked about. > > > > It seems to me that it would be perfectly in line with current = OCSP spec > > to return "unknown" in case the CA has no record of the = certificate being > > asked about. > > > > Current text from RFC 2560: > > The "unknown" state indicates that the responder doesn't know = about > > the certificate being requested. > > > > > > > > Does anyone have a different opinion? > > :) > > Yes. This is the perennial debate, since the early days of OCSP. > > There are actually two discussions. 1/ should we at all allow the > issuance question to be answered in the protocol 2/ if we do, how > should it be expressed? There are good arguments both ways = regarding > 1, but I feel we should, and doing that answer 2 just to put this > dead horse to rest once and for all. > > In my mind the three possible responses are "good", "bad" and = "don't > know, ask someone else if you really want to know". Granted, the > wording of the "unknown" definition is a bit vague, but it cannot = be > read as an affirmative response about the non-existence of a > certificate. The real problem is that "bad" is labeled "revoked" = in > the document and defined only as such. The "good" definition on = the > other hand foresees the issuance question: > > The "good" state indicates a positive response to the = status > inquiry. > At a minimum, this positive response indicates that the > certificate > is not revoked, but does not necessarily mean that the > certificate > was ever issued or that the time at which the response was > produced > is within the certificate's validity interval. Response > extensions > may be used to convey additional information on assertions > made by > the responder regarding the status of the certificate such = as > positive statement about issuance, validity, etc. > > > My position is that reading "unknown" as an assertion of > non-issuance is contrived. It is more reasonable to read it as > "...the responder doesn't know about [the status of] the = certificate > requested" (as in I can't map the CertID to any CA, or I am > temporarily offline with regards to that CA). Looks very much more > like an editing error than anything else. > > The client can only do three thing as a result of an OCSP = response: > accept the certificate, reject it, or try to get better = information > later or at some other place. There is little point in having two > "reject" responses, especially if it comes at the expense of the > "try-somewhere-else-or-come-back-later-if-you-have-time" response. > > I propose that we resolve this by defining the extension that the > "good" definition talks about, and changing the label of "revoked" > to be "bad". I suggest that if you want the responder to answer = the > question about issuance, you use a single request extension to > signal that. And if you want to answer the question, you answer = good > if it is issued and not revoked or bad/revoked if it is non-issued > with reason code certificate hold and an invalidity date at the > beginning of time; adding a single response extension in both = cases > to show that you have considered the issuance question. The exact > syntax of the single request/response extension can be discussed, > but it potentially could include a hash of the certificate at = hand. > > This would leave us with three orthogonal response states: > "good"/"bad"/"don't-know" and clear out a lot of confusion. > > /Simon > > > /Stefan > > > > > > _______________________________________________ > > pkix mailing list > >pkix@ietf.org > >https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email = may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their = own virus checking software. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From rob.stradling@comodo.com Wed Aug 15 08:39:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A750E21F8849 for ; Wed, 15 Aug 2012 08:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLI4CaiiS7OO for ; Wed, 15 Aug 2012 08:39:37 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id B48C421F8847 for ; Wed, 15 Aug 2012 08:39:36 -0700 (PDT) Received: (qmail 11267 invoked from network); 15 Aug 2012 15:39:34 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 15 Aug 2012 15:39:34 -0000 Received: (qmail 12255 invoked by uid 1000); 15 Aug 2012 15:39:34 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 15 Aug 2012 16:39:34 +0100 Message-ID: <502BC23C.4020608@comodo.com> Date: Wed, 15 Aug 2012 16:37:32 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ben@digicert.com References: <502B6F6E.5080707@comodo.com> <007501cd7afa$4cb51180$e61f3480$@digicert.com> In-Reply-To: <007501cd7afa$4cb51180$e61f3480$@digicert.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 15:39:37 -0000 On 15/08/12 16:26, Ben Wilson wrote: > I am very opposed to responding "good" if there is no record of issuance, > that is a lie, too. There are legal liability issues with > misrepresenting the truth In RFC2560, "good" is just a label, and the definition of the label clearly says... The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued... Maybe it was a bad choice of label name. Maybe it was a bad design decision to omit proof of (non-)issuance from the core protocol. But I fail to see how RFC2560's definition of the "good" label misrepresents the truth. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From simon@josefsson.org Wed Aug 15 10:12:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7BA21F8770 for ; Wed, 15 Aug 2012 10:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSpH8tXOV6bN for ; Wed, 15 Aug 2012 10:12:13 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC8521F8772 for ; Wed, 15 Aug 2012 10:12:05 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q7FHBRu4024296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Aug 2012 19:11:29 +0200 From: Simon Josefsson To: Rob Stradling References: <502B6F6E.5080707@comodo.com> <007501cd7afa$4cb51180$e61f3480$@digicert.com> <502BC23C.4020608@comodo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120815:rob.stradling@comodo.com::CTvQpeSQ6zxqDzhj:2OwK X-Hashcash: 1:22:120815:pkix@ietf.org::r2m0WulMwlytSFkR:85hx X-Hashcash: 1:22:120815:ben@digicert.com::oQXgvgUVbNfPG8b1:B73U X-Hashcash: 1:22:120815:stefan@aaa-sec.com::fBcK5kPBGwbYnyhi:C8fy Date: Wed, 15 Aug 2012 19:11:20 +0200 In-Reply-To: <502BC23C.4020608@comodo.com> (Rob Stradling's message of "Wed, 15 Aug 2012 16:37:32 +0100") Message-ID: <874no43wsn.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:12:14 -0000 Rob Stradling writes: > On 15/08/12 16:26, Ben Wilson wrote: > >> I am very opposed to responding "good" if there is no record of issuance, >> that is a lie, too. There are legal liability issues with >> misrepresenting the truth > > In RFC2560, "good" is just a label, and the definition of the label > clearly says... > > The "good" state indicates a positive response to the status inquiry. > At a minimum, this positive response indicates that the certificate > is not revoked, but does not necessarily mean that the certificate > was ever issued... > > Maybe it was a bad choice of label name. Maybe it was a bad design > decision to omit proof of (non-)issuance from the core protocol. > > But I fail to see how RFC2560's definition of the "good" label > misrepresents the truth. I agree -- I don't think we should redefine OCSP semantics now. I believe we should only do editorial fixes to resolve ambiguities and bugs. Stefan's initial proposed text does, I believe, redefine semantics, so I would be against it. Members of CAB forum can address their concern by publishing a OCSP profile that they promise to follow. /Simon From denis.pinkas@bull.net Wed Aug 15 11:08:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409DF11E8091 for ; Wed, 15 Aug 2012 11:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0FHgUogmG2P for ; Wed, 15 Aug 2012 11:08:34 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0DA21F853C for ; Wed, 15 Aug 2012 11:08:33 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 119C01802A; Wed, 15 Aug 2012 20:08:33 +0200 (CEST) In-Reply-To: <502BC23C.4020608@comodo.com> References: <502B6F6E.5080707@comodo.com> <007501cd7afa$4cb51180$e61f3480$@digicert.com> <502BC23C.4020608@comodo.com> To: Rob Stradling MIME-Version: 1.0 X-KeepSent: AA7D25EA:62FB518E-C1257A5B:006216B3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 15 Aug 2012 20:08:32 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 15/08/2012 20:08:32, Serialize complete at 15/08/2012 20:08:32 Content-Type: multipart/alternative; boundary="=_alternative 006388B4C1257A5B_=" Cc: 'pkix' , 'Stefan Santesson' Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:08:35 -0000 Message en plusieurs parties au format MIME --=_alternative 006388B4C1257A5B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Rob, The citation you provided has been truncated. What is important is the=20 end of the text. Hereafter is the full text: The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc. If the certificate was never issued and if the OCSP responder is using=20 only CRLs, it will return good. If the certificate was never issued and if the OCSP responder knows that=20 the certificate was never issued,=20 it will also return "good", but MAY use a single response extension to=20 convey additional information such as=20 a positive statement about issuance. So, the status should be "good" (and not revoked, nor unknown). The question is whether we should take the opportunity of the revision of=20 RFC 2560 to define=20 such a single extension, or leave the definition of such an extension to=20 the CAB forum ? . Denis De : Rob Stradling A : ben@digicert.com Cc : 'Stefan Santesson' , 'pkix' Date : 15/08/2012 17:39 Objet : Re: [pkix] Use of the OSCP unknown response Envoy=E9 par : pkix-bounces@ietf.org On 15/08/12 16:26, Ben Wilson wrote: > I am very opposed to responding "good" if there is no record of=20 issuance, > that is a lie, too. There are legal liability issues with > misrepresenting the truth In RFC2560, "good" is just a label, and the definition of the label=20 clearly says... The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued... Maybe it was a bad choice of label name. Maybe it was a bad design=20 decision to omit proof of (non-)issuance from the core protocol. But I fail to see how RFC2560's definition of the "good" label=20 misrepresents the truth. --=20 Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 006388B4C1257A5B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Rob,

The citation you provided has been &= nbsp;truncated. What is important is the end of the text.
Hereafter is the full text:

   The "good" s= tate indicates a positive response to the status inquiry.
   At a minimum, this pos= itive response indicates that the certificate
   is not revoked, but do= es not necessarily mean that the certificate
   was ever issued or that the time at which the response was produced
   is within the certific= ate's validity interval. Response extensions
   may be used to convey additional information on assertions made by
   the responder regarding the status of the certificate such as
   positive statement abo= ut issuance, validity, etc.

If the certificate was never issued and if the OCSP responder is using only CRLs, it will return good.

If the certificate was never issued and if  the OCSP responder knows that the certificate was never issued,
it will also return "good", but MAY use a single response extensi= on to convey additional information such as
a positive statement about issuance.

So, the status should be "good" (and not revoked, nor unknown).

The question is whether we should take the opportunity of the revision of RFC 2560 to define
such a single extension, or leave the definition of such an extension to the CAB forum ?
.
Denis



De :     &= nbsp;  Rob Stradling <rob.strad= ling@comodo.com>
A :     &n= bsp;  ben@digicert.com
Cc :   &nb= sp;    'Stefan Santesson' <stefan@aaa-sec.com>, 'pkix' <pkix@ietf.org>
Date :    =    15/08/2012 17:39
Objet :        Re: [pkix] Use of the OSCP unknown response
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



On 15/08/12 16:26, Ben Wilson wrote:
<snip>
> I am very opposed to responding "good" if there is no record of issuance,
> that is a lie, too.  There are legal liability issues with
> misrepresenting the truth

In RFC2560, "good" is just a label, and the definition of the label
clearly says...

   The "good" state indicates a positive response to the status inquiry.
   At a minimum, this positive response indicates that the certi= ficate
   is not revoked, but does not necessarily mean that the certif= icate
   was ever issued...

Maybe it was a bad choice of label name.  Maybe it was a bad design
decision to omit proof of (non-)issuance from the core protocol.

But I fail to see how RFC2560's definition of the "good" label
misrepresents the truth.

<snip>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 006388B4C1257A5B_=-- From internet-drafts@ietf.org Wed Aug 15 11:20:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF1821F874C; Wed, 15 Aug 2012 11:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ov3aB-wfGTM; Wed, 15 Aug 2012 11:20:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D8821F86CE; Wed, 15 Aug 2012 11:20:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120815182038.25910.79180.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2012 11:20:38 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-07.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:20:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : Updates to the Internet X.509 Public Key Infrastructure = Certificate and Certificate Revocation List (CRL) Profile Author(s) : Peter E. Yee Filename : draft-ietf-pkix-rfc5280-clarifications-07.txt Pages : 8 Date : 2012-08-15 Abstract: This document updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-rfc5280-clarifications-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc5280-clarifications-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hotz@jpl.nasa.gov Wed Aug 15 11:40:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290F721F8748 for ; Wed, 15 Aug 2012 11:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBCRxJ6HZcRv for ; Wed, 15 Aug 2012 11:40:21 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id A299121F873B for ; Wed, 15 Aug 2012 11:40:21 -0700 (PDT) Received: from dhcp-128-149-190-134.jpl.nasa.gov (dhcp-128-149-190-134.jpl.nasa.gov [128.149.190.134]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7FIeGH5023297 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 15 Aug 2012 11:40:17 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Wed, 15 Aug 2012 11:40:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4B8380B1-E5B9-43EC-A0A2-C8D3A8BC8548@jpl.nasa.gov> References: To: Simon Tardell X-Mailer: Apple Mail (2.1084) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: Stefan Santesson , pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:40:22 -0000 +1 On Aug 15, 2012, at 2:55 AM, Simon Tardell wrote: > I think we should write in the RFC what the client is expected to do = in each case: > "good" it MAY accept the certificate > "revoked" it SHOULD reject the certificate > "unknown" it may try some other revocation source (as defined by = whatever policy you have), or try again later if it has the possibility, = failing that it SHOULD reject the certificate ------- As a separate issue I wish we would include some of T. Miller's = discussion of what an OCSP responder is actually capable of saying. =20 I'm oversimplifying, but basically there are only ever two responses = that a responder can give: if it has a CRL it can say "revoked" or = "unknown" (IMO it would be bad practice to say "good", though the = current spec implies you should say "good" instead of "unknown"). If it = has a white-list, it can say "good" or "unknown". (While the spec might = allow it, I think it would be silly to respond "good" for a cert not on = the white list. ;-) =20 The only way I see to justify three responses is if the responder has = both a black and a white list. The only way I see for an OCSP responder = to provide useful actionable information is if we change something so a = client can consistently interpret and act on the responses, regardless = of what kind of information the OCSP responder is using. If we don't want to change the base definition of "good" so it actually = means on-the-white-list, OK. We can define a "really good" extension, = like Denis says. In that case I don't see any useful distinction = between "good" (but not "really good") and "unknown". ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From denis.pinkas@bull.net Wed Aug 15 11:50:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0030511E808D for ; Wed, 15 Aug 2012 11:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAvfQwrNNX3i for ; Wed, 15 Aug 2012 11:50:20 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 99B1D21F86D5 for ; Wed, 15 Aug 2012 11:50:19 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id B9E541806F for ; Wed, 15 Aug 2012 20:50:18 +0200 (CEST) In-Reply-To: References: <502B6F6E.5080707@comodo.com> <007501cd7afa$4cb51180$e61f3480$@digicert.com> <502BC23C.4020608@comodo.com> To: denis.pinkas@bull.net MIME-Version: 1.0 X-KeepSent: 116B5A1D:335D0C49-C1257A5B:00670400; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 15 Aug 2012 20:50:17 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 15/08/2012 20:50:18, Serialize complete at 15/08/2012 20:50:18 Content-Type: multipart/alternative; boundary="=_alternative 00677954C1257A5B_=" Cc: 'pkix' Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 18:50:21 -0000 Message en plusieurs parties au format MIME --=_alternative 00677954C1257A5B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Errata. Replace:=20 it will also return "good", but MAY use a single response extension to=20 convey additional information such as=20 a positive statement about issuance.=20 with it will also return "good", but SHALL use a single response extension to=20 convey additional information:=20 a negative statement about issuance.=20 Denis De : denis.pinkas@bull.net A : Rob Stradling Cc : 'pkix' , 'Stefan Santesson' Date : 15/08/2012 20:09 Objet : Re: [pkix] Use of the OSCP unknown response Envoy=E9 par : pkix-bounces@ietf.org Rob,=20 The citation you provided has been truncated. What is important is the=20 end of the text.=20 Hereafter is the full text:=20 The "good" state indicates a positive response to the status inquiry.=20 At a minimum, this positive response indicates that the certificate=20 is not revoked, but does not necessarily mean that the certificate=20 was ever issued or that the time at which the response was produced=20 is within the certificate's validity interval. Response extensions=20 may be used to convey additional information on assertions made by=20 the responder regarding the status of the certificate such as=20 positive statement about issuance, validity, etc.=20 If the certificate was never issued and if the OCSP responder is using=20 only CRLs, it will return good.=20 If the certificate was never issued and if the OCSP responder knows that=20 the certificate was never issued,=20 it will also return "good", but MAY use a single response extension to=20 convey additional information such as=20 a positive statement about issuance.=20 So, the status should be "good" (and not revoked, nor unknown).=20 The question is whether we should take the opportunity of the revision of=20 RFC 2560 to define=20 such a single extension, or leave the definition of such an extension to=20 the CAB forum ?=20 .=20 Denis=20 De : Rob Stradling =20 A : ben@digicert.com=20 Cc : 'Stefan Santesson' , 'pkix'=20 =20 Date : 15/08/2012 17:39=20 Objet : Re: [pkix] Use of the OSCP unknown response=20 Envoy=E9 par : pkix-bounces@ietf.org=20 On 15/08/12 16:26, Ben Wilson wrote: > I am very opposed to responding "good" if there is no record of=20 issuance, > that is a lie, too. There are legal liability issues with > misrepresenting the truth In RFC2560, "good" is just a label, and the definition of the label=20 clearly says... The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued... Maybe it was a bad choice of label name. Maybe it was a bad design=20 decision to omit proof of (non-)issuance from the core protocol. But I fail to see how RFC2560's definition of the "good" label=20 misrepresents the truth. --=20 Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 00677954C1257A5B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Errata. Replace:

it will also return "good", but MAY use a single response extension to convey additional informa= tion such as
a positive statement about issuanc= e.

with

it will also return "good", but SHALL use a single response extension to convey additional infor= mation:
a negative statement about issuanc= e.

Denis



De :     &= nbsp;  denis.pinkas@bull.net
A :     &n= bsp;  Rob Stradling <rob.strad= ling@comodo.com>
Cc :   &nb= sp;    'pkix' <pkix@ietf= .org>, 'Stefan Santesson' <stefan@aaa-sec.com>
Date :    =    15/08/2012 20:09
Objet :        Re: [pkix] Use of the OSCP unknown response
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



Rob,

The citation you provided has been  truncated. What is important is the end of the text.
Hereafter is the full text:

  The "good" state indicates a positive response to the status inquiry.
  At a minimum, this positive response indicates that the certificate=
  is not revoked, but does not necessarily mean that the certificate<= /font>
  was ever issued or that the time at which the response was produced=
  is within the certificate's validity interval. Response extensions<= /font>
  may be used to convey additional information on assertions made by
  the responder regarding the status of the certificate such as
  positive statement about issuance, validity, etc.

If the certificate was never issued and if the OCSP responder is using only CRLs, it will return good.

If the certificate was never issued and if  the OCSP responder knows that the certificate was never issued,
it will also return "good", but MAY use a single response extensi= on to convey additional information such as
a positive statement about issuance.

So, the status should be "good" (and not revoked, nor unknown).

The question is whether we should take the opportunity of the revision of RFC 2560 to define
such a single extension, or leave the definition of such an extension to the CAB forum ? =
.
Denis



De :        R= ob Stradling <rob.stradling@comodo.com>
A :        be= n@digicert.com
Cc :        '= Stefan Santesson' <stefan@aaa-sec.com>, 'pkix' <pkix@ietf.org><= font size=3D3>
Date :        15/08/2012 17:39
Objet :        Re: [pkix] Use of the OSCP unknown response
Envoy=E9 par :        pkix-bounces@ietf.org



On 15/08/12 16:26, Ben Wilson wrote:
<snip>
> I am very opposed to responding "good" if there is no record of issuance,
> that is a lie, too.  There are legal liability issues with
> misrepresenting the truth

In RFC2560, "good" is just a label, and the definition of the label
clearly says...

  The "good" state indicates a positive response to the status inquiry.
  At a minimum, this positive response indicates that the certificate=
  is not revoked, but does not necessarily mean that the certificate<= br>   was ever issued...

Maybe it was a bad choice of label name.  Maybe it was a bad design
decision to omit proof of (non-)issuance from the core protocol.

But I fail to see how RFC2560's definition of the "good" label
misrepresents the truth.

<snip>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 00677954C1257A5B_=-- From david.cooper@nist.gov Wed Aug 15 13:03:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1086321F86B3 for ; Wed, 15 Aug 2012 13:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1HRrSJ-qElG for ; Wed, 15 Aug 2012 13:03:08 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id B099B21F86B7 for ; Wed, 15 Aug 2012 13:03:04 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Aug 2012 16:02:57 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Wed, 15 Aug 2012 16:01:14 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q7FK320r008222 for ; Wed, 15 Aug 2012 16:03:02 -0400 Message-ID: <502C0076.3050202@nist.gov> Date: Wed, 15 Aug 2012 16:03:02 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120723 Thunderbird/14.0 MIME-Version: 1.0 To: pkix References: <4B8380B1-E5B9-43EC-A0A2-C8D3A8BC8548@jpl.nasa.gov> In-Reply-To: <4B8380B1-E5B9-43EC-A0A2-C8D3A8BC8548@jpl.nasa.gov> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 20:03:09 -0000 > I'm oversimplifying, but basically there are only ever two responses that a responder can give: if it has a CRL it can say "revoked" or "unknown" (IMO it would be bad practice to say "good", though the current spec implies you should say "good" instead of "unknown"). If it has a white-list, it can say "good" or "unknown". (While the spec might allow it, I think it would be silly to respond "good" for a cert not on the white list. ;-) By this logic, the only response a responder can give is "unknown," unless the request includes a (yet to be defined) extension that includes a copy of the certificate or a hash of the certificate. Since the request only includes hashes of the issuer's name and public key and the serial number of the certificate, even if the responder has a white list, the responder cannot know whether the requester is referring to the certificate on the white list or to a different certificate that just happens to have the same issuer name and serial number, and that has been signed by the same key (or that at least appears to have been signed by the same key). So, I guess that until a new request extension has been defined it would be "silly" for a responder to ever give a response other than "unknown." > The only way I see to justify three responses is if the responder has both a black and a white list. It is very easy to justify three responses as long as you accept that OCSP is a certificate status responder and not a validation server. A response from an OCSP responder, by itself, it useless. The OCSP response only serves to help perform Step (a)(3) in Section 6.1.3 of the path validation algorithm in RFC 5280 (i.e., verify that the certificate is not revoked). Since the labels that are assigned to the three possible responses from the OCSP responder seem to object to the use of one particular response in the case of a certificate that has not been revoked, but for which the responder does not have sufficient information to ensure was issued, let's refer to the responses as (A), (B), and (C). 1. A response of (A) indicates that the responder knows that the specified certificate has not been revoked (whether it was ever issued or not). This means that the certificate satisfies the condition specified in Step (a)(3) in Section 6.1.3 of the path validation algorithm (i.e., it is not revoked). 2. A response of (B) indicates that the responder knows that the specified certificate has been revoked. This means that the certificate does not satisfy the condition specified in Step (a)(3) in Section 6.1.3 of the path validation algorithm, which triggers the following: If any of steps (a), (b), (c), or (f) fails, the procedure terminates, returning a failure indication and an appropriate reason. 3. A response of (C) indicates that the responder does not know the status of the certificate. In this case the client may try another way to verify that the certificate has not been revoked (e.g., ask a different responder or obtain a CRL). [If the client is unable to verify the certificate's revocation status by another means, then it will either have to reject the certificate or make a risk-based decision to accept the certificate despite being unable to verify that it is not revoked.] I would guess that a response of (C) is most likely to occur in the case of a locally trusted OCSP responder. My client may be configured to ask the locally configured OCSP responder first, and then if the response is (C) attempt to determine the certificate's status by using an OCSP responder referenced in the AIA extension in the certificate or by using a CRL obtained via the CDP extension in the certificate. > The only way I see for an OCSP responder to provide useful actionable information is if we change something so a client can consistently interpret and act on the responses, regardless of what kind of information the OCSP responder is using. As noted above, the current protocol already allows an OCSP responder to provide "useful actionable information." Of course, clients won't be able to consistently interpret and act on responses if responders apply their own (personal) interpretations to the three possible status responses. If some developers decide that it is "silly" for a responder to provide a response of (A) unless working from a white list and so have their responders provide a response of (C) for any certificate isn't known to be revoked, then clients will no longer have "useful actionable information." This may not matter for some clients if they are configured to ask the OCSP responder about the certificate, but then continue on with validation unless a response of (B) is received (i.e., if all other aspects of path validation are successful, then accept the certificate even if no response is received from the OCSP responder or if a response of (A), (C), or even a error response is received). However, it will make a big difference to any client configured to fail safe by failing path validation unless it can actually verify that the certificate is not revoked. From ben@digicert.com Wed Aug 15 13:29:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E838A21F8685 for ; Wed, 15 Aug 2012 13:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYvlse36im3w for ; Wed, 15 Aug 2012 13:29:33 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 608A221F8503 for ; Wed, 15 Aug 2012 13:29:33 -0700 (PDT) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id C58E98FA025; Wed, 15 Aug 2012 14:29:32 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1345062572; bh=IF71+4ysHORNUbMjOyrh4awiZFevVSqNR8mLN8QQ12A=; h=Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=xqBBMXvvlWoIRwMfJEoxcorPzOHtXNYAL8HjELs/Kmzxxjk6EBCnHK2NqeBaCjGq9 QU/pPvnRpRNkr+1Fzv47uBisgiWSzw244r8phIYsUO1QAOZVGLN7dNtCqjeX+MvYhp bOGPajWB0++FPHLYesYt2O2lv5TslJTLc5uGCo5Y= From: "Ben Wilson" To: "'David A. Cooper'" , "'pkix'" References: <4B8380B1-E5B9-43EC-A0A2-C8D3A8BC8548@jpl.nasa.gov> <502C0076.3050202@nist.gov> In-Reply-To: <502C0076.3050202@nist.gov> Date: Wed, 15 Aug 2012 14:29:30 -0600 Organization: DigiCert Message-ID: <005b01cd7b24$ac59ae50$050d0af0$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFZDslksM+7LI8ZEjdvMVxxsE2rJAL95eTFAXh895QCREbXJQIU2lebl/2tiWA= Content-Language: en-us Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 20:29:34 -0000 David Cooper wrote: > >unless the request includes a (yet to be defined) extension that includes a copy of the certificate or a hash of the certificate. > What would it take to get clients to hash the certificate, send the hash as part of the OCSP request, and get responders to respond accordingly? From richard.smith@comodo.com Wed Aug 15 14:28:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45EB21F85B4 for ; Wed, 15 Aug 2012 14:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUhX9lraxlOc for ; Wed, 15 Aug 2012 14:28:56 -0700 (PDT) Received: from mail.nj.office.comodo.net (mail.nj.office.comodo.net [38.104.66.254]) by ietfa.amsl.com (Postfix) with ESMTP id B0FCB21F85AF for ; Wed, 15 Aug 2012 14:28:56 -0700 (PDT) Received: (qmail 27083 invoked by uid 1012); 15 Aug 2012 21:28:48 -0000 Received: from Unknown (HELO CGIJC1DWWI1A5) (192.168.65.48) by mail.nj.office.comodo.net (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Wed, 15 Aug 2012 17:28:48 -0400 From: "Rich Smith" To: "'David A. Cooper'" , "'pkix'" References: <4B8380B1-E5B9-43EC-A0A2-C8D3A8BC8548@jpl.nasa.gov> <502C0076.3050202@nist.gov> In-Reply-To: <502C0076.3050202@nist.gov> Date: Wed, 15 Aug 2012 17:28:47 -0400 Organization: Comodo Group, Inc. Message-ID: <046a01cd7b2c$f544b2b0$dfce1810$@smith@comodo.com> X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac17IQMdwCJ1EjWrS1ygzbhzEXkiuQACSYyQ Content-Language: en-us MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0466_01CD7B0B.6D63DBD0" X-Virus-Checked: Checked by ClamAV on mail.nj.office.comodo.net Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: richard.smith@comodo.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 21:28:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0466_01CD7B0B.6D63DBD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Whether you call the responses Good, Revoked and Unknown, OR; A, B and = C, OR; Alice, Bob and Charlie, the RFC is logically flawed in that Good, by containing, "...but does not necessarily mean that the certificate was = ever issued..." overlaps status Unknown. As long as that is the case implementations will be flawed and confused. And since the response is in fact called 'Good' and not 'A', and not 'Alice', a response of 'Good' for an unissued certificate may not, as = Rob has pointed out, misrepresent the truth as per the definition provided = in the RFC, but it most certainly does misrepresent the truth in terms of = what most people understand the word and concept of 'Good' to mean. --=20 Regards, Rich Smith Validation Manager Comodo http://www.comodo.com =A0 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of > David A. Cooper > Sent: Wednesday, August 15, 2012 4:03 PM > To: pkix > Subject: Re: [pkix] Use of the OSCP unknown response >=20 >=20 > > I'm oversimplifying, but basically there are only ever two responses > > that a responder can give: if it has a CRL it can say "revoked" or > > "unknown" (IMO it would be bad practice to say "good", though the > > current spec implies you should say "good" instead of "unknown"). = If > > it has a white-list, it can say "good" or "unknown". (While the = spec > > might allow it, I think it would be silly to respond "good" for a > cert > > not on the white list. ;-) >=20 > By this logic, the only response a responder can give is "unknown," > unless the request includes a (yet to be defined) extension that > includes a copy of the certificate or a hash of the certificate. Since > the request only includes hashes of the issuer's name and public key > and the serial number of the certificate, even if the responder has a > white list, the responder cannot know whether the requester is > referring to the certificate on the white list or to a different > certificate that just happens to have the same issuer name and serial > number, and that has been signed by the same key (or that at least > appears to have been signed by the same key). So, I guess that until = a > new request extension has been defined it would be "silly" for a > responder to ever give a response other than "unknown." >=20 > > The only way I see to justify three responses is if the responder = has > both a black and a white list. >=20 > It is very easy to justify three responses as long as you accept that > OCSP is a certificate status responder and not a validation server. A > response from an OCSP responder, by itself, it useless. The OCSP > response only serves to help perform Step (a)(3) in Section 6.1.3 of > the path validation algorithm in RFC 5280 (i.e., verify that the > certificate is not revoked). >=20 > Since the labels that are assigned to the three possible responses = from > the OCSP responder seem to object to the use of one particular = response > in the case of a certificate that has not been revoked, but for which > the responder does not have sufficient information to ensure was > issued, let's refer to the responses as (A), (B), and (C). >=20 > 1. A response of (A) indicates that the responder knows that the > specified certificate has not been revoked (whether it was ever issued > or not). This means that the certificate satisfies the condition > specified in Step (a)(3) in Section 6.1.3 of the path validation > algorithm (i.e., it is not revoked). >=20 > 2. A response of (B) indicates that the responder knows that the > specified certificate has been revoked. This means that the > certificate does not satisfy the condition specified in Step (a)(3) in > Section 6.1.3 of the path validation algorithm, which triggers the > following: >=20 > If any of steps (a), (b), (c), or (f) fails, the procedure > terminates, returning a failure indication and an appropriate > reason. >=20 > 3. A response of (C) indicates that the responder does not know the > status of the certificate. In this case the client may try another = way > to verify that the certificate has not been revoked (e.g., ask a > different responder or obtain a CRL). [If the client is unable to > verify the certificate's revocation status by another means, then it > will either have to reject the certificate or make a risk-based > decision to accept the certificate despite being unable to verify that > it is not revoked.] >=20 > I would guess that a response of (C) is most likely to occur in the > case of a locally trusted OCSP responder. My client may be configured > to ask the locally configured OCSP responder first, and then if the > response is > (C) attempt to determine the certificate's status by using an OCSP > responder referenced in the AIA extension in the certificate or by > using a CRL obtained via the CDP extension in the certificate. >=20 > > The only way I see for an OCSP responder to provide useful = actionable > information is if we change something so a client can consistently > interpret and act on the responses, regardless of what kind of > information the OCSP responder is using. >=20 > As noted above, the current protocol already allows an OCSP responder > to > provide "useful actionable information." Of course, clients won't be > able to consistently interpret and act on responses if responders = apply > their own (personal) interpretations to the three possible status > responses. If some developers decide that it is "silly" for a > responder to provide a response of (A) unless working from a white = list > and so have their responders provide a response of (C) for any > certificate isn't known to be revoked, then clients will no longer = have > "useful actionable information." This may not matter for some clients > if they are configured to ask the OCSP responder about the = certificate, > but then continue on with validation unless a response of (B) is > received (i.e., if all other aspects of path validation are = successful, > then accept the certificate even if no response is received from the > OCSP responder or if a response of (A), (C), or even a error response > is received). > However, it will make a big difference to any client configured to = fail > safe by failing path validation unless it can actually verify that the > certificate is not revoked. >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0466_01CD7B0B.6D63DBD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUUTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFGjCCBAKgAwIBAgIQbRnq pxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU 4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHff sReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kAB W0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJk JpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IB SzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4 Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVu dF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcN AQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjB MCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8 H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5 OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggZUMIIFPKADAgECAhEAqDR0 NPXZ6UURhku5W7S0lTANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdy ZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTAeFw0xMTA2MTAwMDAwMDBaFw0xNDA2MDkyMzU5NTlaMIIBKTELMAkGA1UEBhMCVVMx DjAMBgNVBBETBTA3MzEwMQswCQYDVQQIEwJOSjEUMBIGA1UEBxMLSmVyc2V5IENpdHkxEjAQBgNV BAkTCVN1aXRlMTQwMDEcMBoGA1UECRMTNTI1IFdhc2hpbmd0b24gQmx2ZDEaMBgGA1UEChMRQ29t b2RvIEdyb3VwIEluYy4xNzA1BgNVBAsTLklzc3VlZCB0aHJvdWdoIENvbW9kbyBHcm91cCBJbmMu IEUtUEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJpY2hhcmQgU21pdGgxJzAlBgkqhkiG9w0BCQEWGHJpY2hhcmQuc21pdGhAY29tb2RvLmNvbTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALMPjP+Ri13hHVrQkDXKpGcoQKrjJ6qGLrOy fTCeyOLlxU0Xk362WTnYfUjDlMBppwDGIFqboM8EwlFr9xh5vhUULy4uU5oiEQeLoDGxVsmmxCZ7 OR2TBdFt9b8YizN01/QeAVbj8JSFtWwiwFtntLEAg8DIG2+Vw/LYxYs8LaT6XySFCX/tCZJSurAO VLIr83xT3yxySkOM0iCXk450FPFSGUaIL1k7oxRgiMD7m8Sj3bHgkT1EZfIcuZVcJfoeqAT1XHlj G6ewQIfStVb2JNTeuIxmu2HDvjdAEVN0bvyVvMoeWpLtAvrI1/VDZzBiwgcTmBjCh2Bt/hLvtbKh fUMCAwEAAaOCAggwggIEMB8GA1UdIwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQW BBS68Ixj5XXWDJB8tE3V+7n7k0gEXjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADApBgNV HSUEIjAgBggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcUAgIwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYD VR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAC hkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wTQYD VR0RBEYwRIEYcmljaGFyZC5zbWl0aEBjb21vZG8uY29toCgGCisGAQQBgjcUAgOgGgwYcmljaGFy ZC5zbWl0aEBjb21vZG8uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAFmeOXSnZsiT8YXbkbodhT82mh 3FvMKehuDnAD6t5f+MeEOUthUw4SCSHM2kCCVUzNeZ3qFsLA1oCJ/PCgwXgwkmPoHaBk8RBteGp2 E6IVrnlJ4QzCfY5h31uhQo7qxcnm0OEpSSIOd/xRyh/LV4I6+qLZz4aB0/FfBV3WaDOfkzuBOYGU kVD0A8lKCIZIbmvhcte5U+6LIrh7suu96RmWwHvAaCBNF7qNEgX20KEtHdW+1IPeNO2C6LlRMcOl zi4pXyc/gD09AaEGI9vMlG/Q81pyHwccUWDVQ+29zjsQ9s4o7q/waHHeuBBnND8YWqGbMrk8DcdJ tqWU3RQ5XaUsMYIEaDCCBGQCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCoNHQ09dnpRRGGS7lbtLSVMAkGBSsOAwIaBQCgggKTMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgxNTIxMjg0N1owIwYJKoZIhvcNAQkEMRYEFCT/zaxp SpU4yPrVctCoPpjrDUxOMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgB ZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCoNHQ09dnpRRGGS7lbtLSVMIG8BgsqhkiG 9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMT MENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAKg0dDT1 2elFEYZLuVu0tJUwDQYJKoZIhvcNAQEBBQAEggEAiXdB2RuP88uyPDFH/AfsZZMeOC6lZFDsJ/9I jxCLcOo4R5QeQ22cGfQTI//LHB2pxg2u5VhS5JfDRRidMgP39abtEj9ZXeW4paF2JebGOaDrIu40 ifl5PdxfbiuwWbUcKD0RgqZjn6713az5FmarwSjmfbhlOpS7ZfbmYPwrFmeanaIHbSkEFTlLAwg6 UznANRXvfDHBylQBkYDARXhdJlivfaEnn0CifHr1FCq0TqG4bEmWesJzaDqVjoAbOf0wvM/TsW+g l+PHD1owBeEXBi+ASZU6eePf3+erPJJ1xCLAJyX+ad6/vW3EvvldPMMFMZKteFQvWHEJnfNdb5RC dwAAAAAAAA== ------=_NextPart_000_0466_01CD7B0B.6D63DBD0-- From hotz@jpl.nasa.gov Wed Aug 15 15:07:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB0921F8530 for ; Wed, 15 Aug 2012 15:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00G7h79HBOfQ for ; Wed, 15 Aug 2012 15:07:50 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id DE89B21F8527 for ; Wed, 15 Aug 2012 15:07:50 -0700 (PDT) Received: from dhcp-128-149-177-193.jpl.nasa.gov (dhcp-128-149-177-193.jpl.nasa.gov [128.149.177.193]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7FM7nRV009337 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 15 Aug 2012 15:07:49 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <502C0076.3050202@nist.gov> Date: Wed, 15 Aug 2012 15:07:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4A6A38EC-442B-48E7-9C9C-39DE969C7ED2@jpl.nasa.gov> References: <4B8380B1-E5B9-43EC-A0A2-C8D3A8BC8548@jpl.nasa.gov> <502C0076.3050202@nist.gov> To: "David A. Cooper" X-Mailer: Apple Mail (2.1084) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 22:07:51 -0000 On Aug 15, 2012, at 1:03 PM, David A. Cooper wrote: > By this logic, the only response a responder can give is "unknown," = unless the request includes a (yet to be defined) extension that = includes a copy of the certificate or a hash of the certificate. Perhaps you're trying to tweak me, but I think I agree with you. ;-) ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From mrex@sap.com Wed Aug 15 16:12:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C9F21F8569 for ; Wed, 15 Aug 2012 16:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.169 X-Spam-Level: X-Spam-Status: No, score=-10.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTmuSw4TBV-A for ; Wed, 15 Aug 2012 16:12:36 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E194721F8568 for ; Wed, 15 Aug 2012 16:12:35 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q7FNCSpw007225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2012 01:12:28 +0200 (MEST) In-Reply-To: <046a01cd7b2c$f544b2b0$dfce1810$@smith@comodo.com> To: richard.smith@comodo.com Date: Thu, 16 Aug 2012 01:12:28 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120815231228.35EC81A17D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'pkix' Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 23:12:37 -0000 Rich Smith wrote: > > Whether you call the responses Good, Revoked and Unknown, OR; A, B and C, > OR; Alice, Bob and Charlie, the RFC is logically flawed in that Good, by > containing, "...but does not necessarily mean that the certificate was ever > issued..." overlaps status Unknown. As long as that is the case > implementations will be flawed and confused. > > And since the response is in fact called 'Good' and not 'A', and not > 'Alice', a response of 'Good' for an unissued certificate may not, as Rob > has pointed out, misrepresent the truth as per the definition provided in > the RFC, but it most certainly does misrepresent the truth in terms of what > most people understand the word and concept of 'Good' to mean. RFC2560 defined only 3 response types: "good", "revoked", "unknown", where what is currently described covers only a fraction of what is actually possible. One of the purposes of OCSP, as defined by rfc2560, is a protocol to outsource CRL checking. The elaborate explanation for "good" is only proof of how lousy CRLs are in the first place, because you really don't know much at all. It seems to have never occured to the architects of X.509 that fraudulent cert issuance could happen, and consumer might appreciate when revocation checking did at least offer some amount of risk management for certain aspects of fraudulently issued certs that subvert the design of CRL-based revocation checking (such as multiple certs from the same CA with the same serial number or certs for which records of issuance were destroyed, so that the CA is not (no longer) aware these certs have been issued). For the way forward, the original description is much less important than the behaviour of the installed base to each of the three responses, and the intention of the CA, which RP behaviour does it want to induce. If a CA runs an OCSP server with access to the cert issue records or the certs database, then this CA might want to send OCSP responses "revoked (on hold)" for all requests about certs that it can not positively identify to have issued. This is not possible for running an OCSP server with a newly invented, periodically issued whitelist of existing certs, unless you're OK with declaring all newly issued certs "revoked (on hold)" as well, until the whitelist update covering the newly issued cert is complete. The "unknown" status looks pretty useless to me for the purpose of conveying "does not exist" status, because it will probably cause RPs in the installed base to perform CRL checking (which is also pure blacklisting), so that extra overhead is likely not going to lead to a better result, but will typically cause additional network round trips and repeat of processing that the OCSP server already did (but could not convey with the 3-state response "good", "revoked", "unknown"). -Martin From denis.pinkas@bull.net Thu Aug 16 06:39:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E7F21F8543 for ; Thu, 16 Aug 2012 06:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT5nUoVRimHn for ; Thu, 16 Aug 2012 06:39:20 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id DB8A921F8525 for ; Thu, 16 Aug 2012 06:39:19 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id D5B5E1809B; Thu, 16 Aug 2012 15:39:18 +0200 (CEST) In-Reply-To: <046a01cd7b2c$f544b2b0$dfce1810$@smith@comodo.com> References: <4B8380B1-E5B9-43EC-A0A2-C8D3A8BC8548@jpl.nasa.gov> <502C0076.3050202@nist.gov> <046a01cd7b2c$f544b2b0$dfce1810$@smith@comodo.com> To: richard.smith@comodo.com MIME-Version: 1.0 X-KeepSent: AE873A77:14F8E91B-C1257A5C:0016ECC5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Thu, 16 Aug 2012 15:39:17 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 16/08/2012 15:39:18, Serialize complete at 16/08/2012 15:39:18 Content-Type: multipart/alternative; boundary="=_alternative 004AEBE2C1257A5C_=" Cc: 'pkix' Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 13:39:22 -0000 Message en plusieurs parties au format MIME --=_alternative 004AEBE2C1257A5C_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Rich, There is indeed a solution which uses the current text of RFC 2560,=20 without the need to tweak any current meaning=20 of "good", "revoked" or "unknown". The solution allows all current OCSP clients (if they comply with RFC=20 2560) to reject the target certificate. The solution allows "new" OCSP clients, compliant of the solution, to know = that a white list of certificates=20 has been used by the OCSP server and that the target serial number is=20 unknown in that list. In order to provide everybody with the opportunity to find the solution by = himself, I will post additional information=20 a little bit later in another post, as a reply to Henry B. Hotz. :-) Denis De : "Rich Smith" A : "'David A. Cooper'" , "'pkix'"=20 Date : 15/08/2012 23:29 Objet : Re: [pkix] Use of the OSCP unknown response Envoy=E9 par : pkix-bounces@ietf.org Whether you call the responses Good, Revoked and Unknown, OR; A, B and C, OR; Alice, Bob and Charlie, the RFC is logically flawed in that Good, by containing, "...but does not necessarily mean that the certificate was=20 ever issued..." overlaps status Unknown. As long as that is the case implementations will be flawed and confused. And since the response is in fact called 'Good' and not 'A', and not 'Alice', a response of 'Good' for an unissued certificate may not, as Rob has pointed out, misrepresent the truth as per the definition provided in the RFC, but it most certainly does misrepresent the truth in terms of=20 what most people understand the word and concept of 'Good' to mean. --=20 Regards, Rich Smith Validation Manager Comodo http://www.comodo.com =20 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > David A. Cooper > Sent: Wednesday, August 15, 2012 4:03 PM > To: pkix > Subject: Re: [pkix] Use of the OSCP unknown response >=20 >=20 > > I'm oversimplifying, but basically there are only ever two responses > > that a responder can give: if it has a CRL it can say "revoked" or > > "unknown" (IMO it would be bad practice to say "good", though the > > current spec implies you should say "good" instead of "unknown"). If > > it has a white-list, it can say "good" or "unknown". (While the spec > > might allow it, I think it would be silly to respond "good" for a > cert > > not on the white list. ;-) >=20 > By this logic, the only response a responder can give is "unknown," > unless the request includes a (yet to be defined) extension that > includes a copy of the certificate or a hash of the certificate. Since > the request only includes hashes of the issuer's name and public key > and the serial number of the certificate, even if the responder has a > white list, the responder cannot know whether the requester is > referring to the certificate on the white list or to a different > certificate that just happens to have the same issuer name and serial > number, and that has been signed by the same key (or that at least > appears to have been signed by the same key). So, I guess that until a > new request extension has been defined it would be "silly" for a > responder to ever give a response other than "unknown." >=20 > > The only way I see to justify three responses is if the responder has > both a black and a white list. >=20 > It is very easy to justify three responses as long as you accept that > OCSP is a certificate status responder and not a validation server. A > response from an OCSP responder, by itself, it useless. The OCSP > response only serves to help perform Step (a)(3) in Section 6.1.3 of > the path validation algorithm in RFC 5280 (i.e., verify that the > certificate is not revoked). >=20 > Since the labels that are assigned to the three possible responses from > the OCSP responder seem to object to the use of one particular response > in the case of a certificate that has not been revoked, but for which > the responder does not have sufficient information to ensure was > issued, let's refer to the responses as (A), (B), and (C). >=20 > 1. A response of (A) indicates that the responder knows that the > specified certificate has not been revoked (whether it was ever issued > or not). This means that the certificate satisfies the condition > specified in Step (a)(3) in Section 6.1.3 of the path validation > algorithm (i.e., it is not revoked). >=20 > 2. A response of (B) indicates that the responder knows that the > specified certificate has been revoked. This means that the > certificate does not satisfy the condition specified in Step (a)(3) in > Section 6.1.3 of the path validation algorithm, which triggers the > following: >=20 > If any of steps (a), (b), (c), or (f) fails, the procedure > terminates, returning a failure indication and an appropriate > reason. >=20 > 3. A response of (C) indicates that the responder does not know the > status of the certificate. In this case the client may try another way > to verify that the certificate has not been revoked (e.g., ask a > different responder or obtain a CRL). [If the client is unable to > verify the certificate's revocation status by another means, then it > will either have to reject the certificate or make a risk-based > decision to accept the certificate despite being unable to verify that > it is not revoked.] >=20 > I would guess that a response of (C) is most likely to occur in the > case of a locally trusted OCSP responder. My client may be configured > to ask the locally configured OCSP responder first, and then if the > response is > (C) attempt to determine the certificate's status by using an OCSP > responder referenced in the AIA extension in the certificate or by > using a CRL obtained via the CDP extension in the certificate. >=20 > > The only way I see for an OCSP responder to provide useful actionable > information is if we change something so a client can consistently > interpret and act on the responses, regardless of what kind of > information the OCSP responder is using. >=20 > As noted above, the current protocol already allows an OCSP responder > to > provide "useful actionable information." Of course, clients won't be > able to consistently interpret and act on responses if responders apply > their own (personal) interpretations to the three possible status > responses. If some developers decide that it is "silly" for a > responder to provide a response of (A) unless working from a white list > and so have their responders provide a response of (C) for any > certificate isn't known to be revoked, then clients will no longer have > "useful actionable information." This may not matter for some clients > if they are configured to ask the OCSP responder about the certificate, > but then continue on with validation unless a response of (B) is > received (i.e., if all other aspects of path validation are successful, > then accept the certificate even if no response is received from the > OCSP responder or if a response of (A), (C), or even a error response > is received). > However, it will make a big difference to any client configured to fail > safe by failing path validation unless it can actually verify that the > certificate is not revoked. >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix [pi=E8ce jointe "smime.p7s" supprim=E9e par Denis PINKAS/FR/BULL]=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 004AEBE2C1257A5C_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Rich,

There is indeed a solution which uses the current text of RFC 2560, without the need to tweak any current meaning
of "good", "revoked" or "unknown".

The solution allows all current OCSP clients (if they comply with RFC 2560) to reject the target certificate.

The solution allows "new" OCSP clients, compliant of the solution, to know that a white list of certi= ficates
has been used by the OCSP server and that the target serial number is unkno= wn in that list.

In order to provide everybody with t= he opportunity to find the solution by himself, I will post additional  i= nformation
a little bit later in another post, as a reply to Henry B. Hotz.

:-)

Denis



De :     &= nbsp;  "Rich Smith" <richard.smith@comodo.com>
A :     &n= bsp;  "'David A. Cooper'&quo= t; <david.cooper@nist.gov>, "'pkix'" <pkix@ietf.org>
Date :    =    15/08/2012 23:29
Objet :        Re: [pkix] Use of the OSCP unknown response
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g



Whether you call the responses Good, Revoked and Unk= nown, OR; A, B and C,
OR; Alice, Bob and Charlie, the RFC is logically flawed in that Good, by
containing, "...but does not necessarily mean that the certificate was ever
issued..." overlaps status Unknown.  As long as that is the case<= br> implementations will be flawed and confused.

And since the response is in fact called 'Good' and not 'A', and not
'Alice', a response of 'Good' for an unissued certificate may not, as Rob has pointed out, misrepresent the truth as per the definition provided in
the RFC, but it most certainly does misrepresent the truth in terms of what
most people understand the word and concept of 'Good' to mean.

--
Regards,
Rich Smith
Validation Manager
Comodo
http://www.= comodo.com
 



> -----Original Message-----
> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org= ] On Behalf Of
> David A. Cooper
> Sent: Wednesday, August 15, 2012 4:03 PM
> To: pkix
> Subject: Re: [pkix] Use of the OSCP unknown response
>
>
> > I'm oversimplifying, but basically there are only ever two respon= ses
> > that a responder can give:  if it has a CRL it can say "= ;revoked" or
> > "unknown" (IMO it would be bad practice to say "go= od", though the
> > current spec implies you should say "good" instead of "unknown").  If
> > it has a white-list, it can say "good" or "unknown= ".  (While the spec
> > might allow it, I think it would be silly to respond "good&q= uot; for a
> cert
> > not on the white list. ;-)
>
> By this logic, the only response a responder can give is "unknown= ,"
> unless the request includes a (yet to be defined) extension that
> includes a copy of the certificate or a hash of the certificate. Since=
> the request only includes hashes of the issuer's name and public key > and the serial number of the certificate, even if the responder has a
> white list, the responder cannot know whether the requester is
> referring to the certificate on the white list or to a different
> certificate that just happens to have the same issuer name and serial<= br> > number, and that has been signed by the same key (or that at least
> appears to have been signed by the same key).  So, I guess that until a
> new request extension has been defined it would be "silly" for a
> responder to ever give a response other than "unknown."
>
> > The only way I see to justify three responses is if the responder has
> both a black and a white list.
>
> It is very easy to justify three responses as long as you accept that<= br> > OCSP is a certificate status responder and not a validation server.  A
> response from an OCSP responder, by itself, it useless. The OCSP
> response only serves to help perform Step (a)(3) in Section 6.1.3 of
> the path validation algorithm in RFC 5280 (i.e., verify that the
> certificate is not revoked).
>
> Since the labels that are assigned to the three possible responses from
> the OCSP responder seem to object to the use of one particular respons= e
> in the case of a certificate that has not been revoked, but for which<= br> > the responder does not have sufficient information to ensure was
> issued, let's refer to the responses as (A), (B), and (C).
>
> 1.  A response of (A) indicates that the responder knows that the
> specified certificate has not been revoked (whether it was ever issued=
> or not).  This means that the certificate satisfies the condition=
> specified in Step (a)(3) in Section 6.1.3 of the path validation
> algorithm (i.e., it is not revoked).
>
> 2. A response of (B) indicates that the responder knows that the
> specified certificate has been revoked.  This means that the
> certificate does not satisfy the condition specified in Step (a)(3) in
> Section 6.1.3 of the path validation algorithm, which triggers the
> following:
>
>     If any of steps (a), (b), (c), or (f) fails, the procedu= re
>     terminates, returning a failure indication and an approp= riate
> reason.
>
> 3. A response of (C) indicates that the responder does not know the
> status of the certificate.  In this case the client may try anoth= er way
> to verify that the certificate has not been revoked (e.g., ask a
> different responder or obtain a CRL).  [If the client is unable to
> verify the certificate's revocation status by another means, then it
> will either have to reject the certificate or make a risk-based
> decision to accept the certificate despite being unable to verify that
> it is not revoked.]
>
> I would guess that a response of (C) is most likely to occur in the
> case of a locally trusted OCSP responder.  My client may be confi= gured
> to ask the locally configured OCSP responder first, and then if the
> response is
> (C) attempt to determine the certificate's status by using an OCSP
> responder referenced in the AIA extension in the certificate or by
> using a CRL obtained via the CDP extension in the certificate.
>
> > The only way I see for an OCSP responder to provide useful action= able
> information is if we change something so a client can consistently
> interpret and act on the responses, regardless of what kind of
> information the OCSP responder is using.
>
> As noted above, the current protocol already allows an OCSP responder<= br> > to
> provide "useful actionable information."   Of course, clients won't be
> able to consistently interpret and act on responses if responders apply
> their own (personal) interpretations to the three possible status
> responses.  If some developers decide that it is "silly" for a
> responder to provide a response of (A) unless working from a white list
> and so have their responders provide a response of (C) for any
> certificate isn't known to be revoked, then clients will no longer have
> "useful actionable information."  This may not matter for some clients
> if they are configured to ask the OCSP responder about the certificate= ,
> but then continue on with validation unless a response of (B) is
> received (i.e., if all other aspects of path validation are successful= ,
> then accept the certificate even if no response is received from the > OCSP responder or if a response of (A), (C), or even a error response<= br> > is received).
> However, it will make a big difference to any client configured to fail
> safe by failing path validation unless it can actually verify that the
> certificate is not revoked.
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> pkix mailing list
> pkix@ietf.org
> <= font size=3D2>https://www.ietf.org/mailman/listinfo/pkix
[pi=E8ce jointe "smime.p7s" supprim=E9e par Denis PINKAS/FR/BULL] =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 004AEBE2C1257A5C_=-- From kent@bbn.com Thu Aug 16 06:45:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6131421F849A for ; Thu, 16 Aug 2012 06:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zP2j4r8eiNt for ; Thu, 16 Aug 2012 06:45:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E4FBB21F8498 for ; Thu, 16 Aug 2012 06:45:13 -0700 (PDT) Received: from dhcp89-089-055.bbn.com ([128.89.89.55]:53478) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T20Ns-0008p5-C7 for pkix@ietf.org; Thu, 16 Aug 2012 09:45:12 -0400 Message-ID: <502CF968.4030003@bbn.com> Date: Thu, 16 Aug 2012 09:45:12 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: pkix Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] draft-ietf-pkix-rfc5280-clarifications-07.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 13:45:14 -0000 With the publication of this version of this document, Stefan, Sean, and I have decided that this WG item is now closed. It will be forwarded to the IESG shortly. Steve From internet-drafts@ietf.org Thu Aug 16 10:52:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A023C21F85EF; Thu, 16 Aug 2012 10:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0crTPomNfb5B; Thu, 16 Aug 2012 10:52:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7216821F85ED; Thu, 16 Aug 2012 10:52:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120816175248.28634.80488.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2012 10:52:48 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-08.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:52:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : Updates to the Internet X.509 Public Key Infrastructure = Certificate and Certificate Revocation List (CRL) Profile Author(s) : Peter E. Yee Filename : draft-ietf-pkix-rfc5280-clarifications-08.txt Pages : 8 Date : 2012-08-16 Abstract: This document updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-rfc5280-clarifications-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc5280-clarifications-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From denis.pinkas@bull.net Fri Aug 17 00:57:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319BD21F856F for ; Fri, 17 Aug 2012 00:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCQRx+4YDxYK for ; Fri, 17 Aug 2012 00:57:36 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4E21F8472 for ; Fri, 17 Aug 2012 00:57:36 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 9ACCD1812E; Fri, 17 Aug 2012 09:57:34 +0200 (CEST) In-Reply-To: <4A6A38EC-442B-48E7-9C9C-39DE969C7ED2@jpl.nasa.gov> References: <4B8380B1-E5B9-43EC-A0A2-C8D3A8BC8548@jpl.nasa.gov> <502C0076.3050202@nist.gov> <4A6A38EC-442B-48E7-9C9C-39DE969C7ED2@jpl.nasa.gov> To: "Henry B. Hotz" MIME-Version: 1.0 X-KeepSent: 69C9EE36:E5F0C66E-C1257A5C:0017D7B5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Fri, 17 Aug 2012 09:57:33 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 17/08/2012 09:57:34, Serialize complete at 17/08/2012 09:57:34 Content-Type: multipart/alternative; boundary="=_alternative 002BA3FCC1257A5D_=" Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:57:37 -0000 Message en plusieurs parties au format MIME --=_alternative 002BA3FCC1257A5D_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Follow up of the previous mail on the same topic. There is a solution which does not use any extension in the request. This solution uses a new singleResponse extension, which indicates that=20 the serial number of the certificate is not present=20 in the list of the certificates issued by the CA to which the OCSP=20 responder has access. When this extension contains that indication, the critical flag SHALL be=20 set. OCSP clients unable to process this singleResponse extension SHALL=20 consider that the content of the single response=20 cannot be interpreted (this is the usual way to process an extension that=20 is marked critical) and this leads to an error=20 case (e.g. single response content invalid). Clients able to process this singleResponse extension will know that the=20 serial number of the certificate is not present=20 in the list of the certificates issued by the CA to which the OCSP=20 responder has access. Denis=20 De : "Henry B. Hotz" A : "David A. Cooper" Cc : pkix Date : 16/08/2012 00:20 Objet : Re: [pkix] Use of the OSCP unknown response Envoy=E9 par : pkix-bounces@ietf.org On Aug 15, 2012, at 1:03 PM, David A. Cooper wrote: > By this logic, the only response a responder can give is "unknown,"=20 unless the request includes a (yet to be defined) extension that includes=20 a copy of the certificate or a hash of the certificate. Perhaps you're trying to tweak me, but I think I agree with you. ;-) ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 002BA3FCC1257A5D_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Follow up of the previous mail on the sa= me topic.

There is a solution which does not use any extension in the request.

This solution uses a new singleResponse e= xtension, which indicates that the serial number of the certificate is not present
in the list of the certificates issued by the CA to which the OCSP responder has access.

When this extension contains that indicat= ion, the critical flag SHALL be set.

OCSP clients unable to process this singl= eResponse extension SHALL consider that the content of the single response
cannot be interpreted (this is the usual way to process an extension that is marked critical) and this leads to an error
case (e.g. single response content invalid).

Clients able to process this singleRespon= se extension will know that the serial number of the certificate is not present
in the list of the certificates issued by the CA to which the OCSP responder has access.

Denis



De :     &= nbsp;  "Henry B. Hotz" <hotz@jpl.nasa.gov>
A :     &n= bsp;  "David A. Cooper" <david.cooper@nist.gov>
Cc :   &nb= sp;    pkix <pkix@ietf.o= rg>
Date :    =    16/08/2012 00:20
Objet :        Re: [pkix] Use of the OSCP unknown response
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g




On Aug 15, 2012, at 1:03 PM, David A. Cooper wrote:

> By this logic, the only response a responder can give is "unknown= ," unless the request includes a (yet to be defined) extension that includes a copy of the certificate or a hash of the certificate.

Perhaps you're trying to tweak me, but I think I agree with you.  ;-)<= br> ------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 002BA3FCC1257A5D_=-- From mrex@sap.com Fri Aug 17 17:25:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A87021F8472 for ; Fri, 17 Aug 2012 17:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.171 X-Spam-Level: X-Spam-Status: No, score=-10.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6pY910+2v+o for ; Fri, 17 Aug 2012 17:25:09 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8816D21F846D for ; Fri, 17 Aug 2012 17:25:09 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7I0P2PL022637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Aug 2012 02:25:07 +0200 (MEST) In-Reply-To: To: denis.pinkas@bull.net Date: Sat, 18 Aug 2012 02:25:02 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120818002502.9282E1A195@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 00:25:10 -0000 denis.pinkas@bull.net wrote: > Follow up of the previous mail on the same topic. > > There is a solution which does not use any extension in the request. Uh-oh! If the OCSP requestor does not indicate that it supports new response semantics, then the OCSP responder can not distinguish rfc2560 clients from updated clients! The prerequisite for any negotiation of new features is that the requst contains an indication about the clients additional capabilities. Without it, the server should not be _extremely_ conservative about changes in the response. > > This solution uses a new singleResponse extension, which indicates that > the serial number of the certificate is not present > in the list of the certificates issued by the CA to which the OCSP > responder has access. > > When this extension contains that indication, the critical flag SHALL be > set. Now that looks quite dangerous to me. A client that did not indicate to understand the extension is indistinguishable from an simple rfc2560 client. And the simple rfc2560 should drop the OCSP response with an unrecognized critical extension. Which will either result in the client to skip OCSP checking (bad) or to try other responders or CRLs (also bad). What the (CAs) OCSP responder should answer depends on what the OCSP responder wants the client/RP to do. If the OCSP responder wants the client/RP to *NOT* trust that cert, then "revoked (on hold)" is the only sensible response. If the OCSP responder wants to include this information only for those (new/updated) clients/RP that care about this info, then "good" with a non-critical extension would be OK. "unknown" implies that the client/RP should ask someone else, and a non-marginal number of client/RPs might skip the revocation check when receiving an unknown response (treating it similar to a network connection failure to the OCSP responder). > > OCSP clients unable to process this singleResponse extension SHALL > consider that the content of the single response > cannot be interpreted (this is the usual way to process an extension that > is marked critical) and this leads to an error > case (e.g. single response content invalid). This leads to the client/RP either skipping revocation or falling back to CRL checking--where the "not issued" state can not be conveyed at all. I consider this behaviour non-sensical with respect to the installed base. > > Clients able to process this singleResponse extension will know that the > serial number of the certificate is not present > in the list of the certificates issued by the CA to which the OCSP > responder has access. Client/RPs do not want to know that. They instead want to know "can I trust this cert"? An OCSP server that says "This cert may have not been issued" rather than "Do NOT trust this cert" is chickening out. In order to make a whitelist check reasonably foolproof, the client/RP should send either the whole cert or at least the certificate(!) hash and the validity of the certificate in the OCSP request. The whitelist lookup should be performed with the certificate hash, and the validity enables an OCSP responder to determine whether the whitelist records it has access to are sufficiently "fresh" to determine whether the cert in question has been issued. -Martin From tom@ritter.vg Sun Aug 19 08:58:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCE921F851C for ; Sun, 19 Aug 2012 08:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuJyPZsqEczA for ; Sun, 19 Aug 2012 08:58:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC39921F8517 for ; Sun, 19 Aug 2012 08:58:29 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5403190vbb.31 for ; Sun, 19 Aug 2012 08:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qdoj1I/eXSOG6k+9e8vJ+TvVgAwot/gwt5Drut08Wgc=; b=NeZOVvtyW77DPa2LHeXBtyrnqcT3vP0ABSjurBDvheKtobdHZG0oRLoAvSEJTPuLK7 dIIsUvQpDry1oFU0fNpNSVT8m7wbR3qtlBn05LTCovlke0k0A7E8w5mnjFfyL9c7yByd 42BdOouziF0tZc0lvR1iB7NiCCd9hrOhsdslI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Qdoj1I/eXSOG6k+9e8vJ+TvVgAwot/gwt5Drut08Wgc=; b=LBeCVw6nFu6Hf8FnweMZuT7U6rkuf5saCu6ESI1/BTsqrJn0li/ZFO2RngzMIXha9o 1ceRokgJ+2Zo0wVwomqsWKQReZ6zwQO32wA7pdAwesDXXHI5bPFmZms8LfE5hhBBrF40 nsiZ16TH0uIvaRkyWjw5OrKnGsOme7ord1DURFvd78iwPVgTk7bRdkNojvcPgQPn4Izl rnO6q75Z+PLi4LUBi2V9JjQfLj3YiFrFqwCjj2U8HG8XEPkTImQEx8gBXgRts1lb6Sne Lf/R0hB8dhLVUn5BgZCrvMfsBB9bVf83/6FK9wmSeqaFLTyK34auqzWh9iJyo+yFF3xS OoNg== MIME-Version: 1.0 Received: by 10.52.20.143 with SMTP id n15mr6634709vde.112.1345391909017; Sun, 19 Aug 2012 08:58:29 -0700 (PDT) Received: by 10.58.239.200 with HTTP; Sun, 19 Aug 2012 08:58:28 -0700 (PDT) Received: by 10.58.239.200 with HTTP; Sun, 19 Aug 2012 08:58:28 -0700 (PDT) In-Reply-To: <20120818002502.9282E1A195@ld9781.wdf.sap.corp> References: <20120818002502.9282E1A195@ld9781.wdf.sap.corp> Date: Sun, 19 Aug 2012 11:58:28 -0400 Message-ID: From: Tom Ritter To: mrex@sap.com Content-Type: multipart/alternative; boundary=20cf307d05bad21a1904c7a0765a X-Gm-Message-State: ALoCoQmDEwbIu7VicWGrekIF06bccfGUV1IuV9XJVpTac6aAvrz5ppJC2dNKAuOf3YSlrlWwkMa7 Cc: IETF PKIX Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 15:58:30 -0000 --20cf307d05bad21a1904c7a0765a Content-Type: text/plain; charset=ISO-8859-1 On Aug 17, 2012 8:25 PM, "Martin Rex" wrote: > Client/RPs do not want to know that. They instead want to know > "can I trust this cert"? An OCSP server that says "This cert may have > not been issued" rather than "Do NOT trust this cert" is chickening out. > > > In order to make a whitelist check reasonably foolproof, the client/RP > should send either the whole cert or at least the certificate(!) hash > and the validity of the certificate in the OCSP request. > > The whitelist lookup should be performed with the certificate hash, > and the validity enables an OCSP responder to determine whether the > whitelist records it has access to are sufficiently "fresh" to > determine whether the cert in question has been issued. I agree with this completely, including hash lookups. Trying to map blacklist and whitelist information is not what the client is interested in. It's very rare that a responder should say "I can't assertively speak for this certificate, go elsewhere." The responder should be giving "trust this" or "don't trust this". --20cf307d05bad21a1904c7a0765a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Aug 17, 2012 8:25 PM, "Martin Rex" <mrex@sap.com> wrote:
> Client/RPs do not want to know that. =A0They instead want to know
> "can I trust this cert"? =A0An OCSP server that says "T= his cert may have
> not been issued" rather than "Do NOT trust this cert" i= s chickening out.
>
>
> In order to make a whitelist check reasonably foolproof, the client/RP=
> should send either the whole cert or at least the certificate(!) hash<= br> > and the validity of the certificate in the OCSP request.
>
> The whitelist lookup should be performed with the certificate hash, > and the validity enables an OCSP responder to determine whether the > whitelist records it has access to are sufficiently "fresh" = to
> determine whether the cert in question has been issued.

I agree with this completely, including hash lookups.

Trying to map blacklist and whitelist information is not wha= t the client is interested in.=A0 It's very rare that a responder shoul= d say "I can't assertively speak for this certificate, go elsewher= e." The responder should be giving "trust this" or "don= 't trust this".

--20cf307d05bad21a1904c7a0765a-- From turners@ieca.com Sun Aug 19 14:22:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECEB21F8600 for ; Sun, 19 Aug 2012 14:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.375 X-Spam-Level: X-Spam-Status: No, score=-101.375 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUc1d5E8LxVM for ; Sun, 19 Aug 2012 14:22:33 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.93.136.19]) by ietfa.amsl.com (Postfix) with ESMTP id AFCC021F85FC for ; Sun, 19 Aug 2012 14:22:33 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id C0E07F116D8CD; Sun, 19 Aug 2012 16:22:33 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id B5BBBF116D899 for ; Sun, 19 Aug 2012 16:22:33 -0500 (CDT) Received: from [108.18.174.220] (port=60067 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1T3Cx6-00067N-RV; Sun, 19 Aug 2012 16:22:32 -0500 Message-ID: <50315918.5010802@ieca.com> Date: Sun, 19 Aug 2012 17:22:32 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: saag@ietf.org, pkix@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:60067 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [pkix] new mailing list: wpkops X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 21:22:34 -0000 A new non-working group mailing list has been created and subscription information can be found at: https://www.ietf.org/mailman/listinfo/wpkops The purpose of the mailing list is to discussion the following topics: - How the Web PKI currently works - Shortcomings and failure modes of the current Web PKI - Future evolution of Web PKI - Advice to those developing Web PKI clients If you were at the SAAG session at IETF 84 [1], you might remember that we talked about having a BoF at IETF 85 to consider formation of a Working Group on one or more of these topics. For that reason, discussion in the immediate future should probably focus on the scope and objectives of such a Working Group. [1] http://www.ietf.org/proceedings/84/slides/slides-84-saag-0.pdf Cheers, Stephen and Sean From denis.pinkas@bull.net Mon Aug 20 00:29:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDEF21F862A for ; Mon, 20 Aug 2012 00:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diH77dhcMrYy for ; Mon, 20 Aug 2012 00:29:28 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4264A21F8653 for ; Mon, 20 Aug 2012 00:29:27 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 2B93E18153; Mon, 20 Aug 2012 09:29:27 +0200 (CEST) In-Reply-To: <20120818002502.9282E1A195@ld9781.wdf.sap.corp> References: <20120818002502.9282E1A195@ld9781.wdf.sap.corp> To: mrex@sap.com MIME-Version: 1.0 X-KeepSent: D575CDB4:A61FED00-C1257A5F:00226301; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Mon, 20 Aug 2012 09:29:26 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 20/08/2012 09:29:26, Serialize complete at 20/08/2012 09:29:26 Content-Type: multipart/alternative; boundary="=_alternative 00290066C1257A60_=" Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 07:29:29 -0000 Message en plusieurs parties au format MIME --=_alternative 00290066C1257A60_= Content-Type: text/plain; charset="US-ASCII" Martin, See my responses in the text below: De : mrex@sap.com (Martin Rex) A : denis.pinkas@bull.net Cc : "Henry B. Hotz" , pkix Date : 18/08/2012 02:25 Objet : Re: [pkix] Use of the OSCP unknown response > Follow up of the previous mail on the same topic. > > There is a solution which does not use any extension in the request. Uh-oh! If the OCSP requestor does not indicate that it supports new response semantics, then the OCSP responder can not distinguish rfc2560 clients from updated clients! The prerequisite for any negotiation of new features is that the request contains an indication about the clients additional capabilities. Without it, the server should not be _extremely_ conservative about changes in the response. [Denis: No. The solution does not need any change in the request] > This solution uses a new singleResponse extension, which indicates that > the serial number of the certificate is not present > in the list of the certificates issued by the CA to which the OCSP > responder has access. > > When this extension contains that indication, the critical flag SHALL be > set. Now that looks quite dangerous to me. A client that did not indicate to understand the extension is indistinguishable from an simple rfc2560 client. And the simple rfc2560 should drop the OCSP response with an unrecognized critical extension. Which will either result in the client to skip OCSP checking (bad) or to try other responders or CRLs (also bad). [Denis: An OCSP client which does not recognize a critical extension within singleExtensions SHALL drop the individual response where that critical extension is present but may accept other responses within the field responses"] What the (CAs) OCSP responder should answer depends on what the OCSP responder wants the client/RP to do. If the OCSP responder wants the client/RP to *NOT* trust that cert, then "revoked (on hold)" is the only sensible response. [Denis: Again, if a critical extension is present within singleExtensions in an individual response then the client SHALL drop the individual response whatever the value of CertStatus may be. So it is irrelevant to argue about the value of the CertStatus] If the OCSP responder wants to include this information only for those (new/updated) clients/RP that care about this info, then "good" with a non-critical extension would be OK. [Denis: No. See above] "unknown" implies that the client/RP should ask someone else, and a non-marginal number of client/RPs might skip the revocation check when receiving an unknown response (treating it similar to a network connection failure to the OCSP responder). [Denis: No. See above] > OCSP clients unable to process this singleResponse extension SHALL > consider that the content of the single response > cannot be interpreted (this is the usual way to process an extension that > is marked critical) and this leads to an error > case (e.g. single response content invalid). This leads to the client/RP either skipping revocation or falling back to CRL checking--where the "not issued" state can not be conveyed at all. I consider this behaviour non-sensical with respect to the installed base. [Denis: Compliant clients shall not skip revocation as you say. However, your second argument is a valid consideration. I am preparing a draft for the definition of a new extension within singleExtensions and I have added the following note: NOTE: OCSP clients should not use a fallback mechanism based on CRLs when they encounter within singleExtensions an extension which is not understood and which is marked critical.] > Clients able to process this singleResponse extension will know that the > serial number of the certificate is not present > in the list of the certificates issued by the CA to which the OCSP > responder has access. Client/RPs do not want to know that. They instead want to know "can I trust this cert"? An OCSP server that says "This cert may have not been issued" rather than "Do NOT trust this cert" is chickening out. In order to make a whitelist check reasonably foolproof, the client/RP should send either the whole cert or at least the certificate(!) hash and the validity of the certificate in the OCSP request. [Denis: In the draft I am preparing, the server may return the hash. So you get the same property, but without the need to change the syntax of the request. Note: the client may not know in advance whether the server is using or not white lists] The whitelist lookup should be performed with the certificate hash, and the validity enables an OCSP responder to determine whether the whitelist records it has access to are sufficiently "fresh" to determine whether the cert in question has been issued. [Denis: returning the hash provides the same benefit. The comparison will be done by the client rather than by the server]. -Martin --=_alternative 00290066C1257A60_= Content-Type: text/html; charset="US-ASCII" Martin,

See my responses in the text below:




De :        mrex@sap.com (Martin Rex)
A :        denis.pinkas@bull.net
Cc :        "Henry B. Hotz" <hotz@jpl.nasa.gov>, pkix <pkix@ietf.org>
Date :        18/08/2012 02:25
Objet :        Re: [pkix] Use of the OSCP unknown response


> Follow up of the previous mail on the same topic.
>
> There is a solution which does not use any extension in the request.

Uh-oh!

If the OCSP requestor does not indicate that it supports new response
semantics, then the OCSP responder can not distinguish rfc2560 clients
from updated clients!

The prerequisite for any negotiation of new features is that
the request contains an indication about the clients additional
capabilities.  Without it, the server should not be _extremely_
conservative about changes in the response.
[Denis: No. The solution does not need any change in the request]

> This solution uses a new singleResponse extension, which indicates that
> the serial number of the certificate is not present
> in the list of the certificates issued by the CA to which the OCSP
> responder has access.
>
> When this extension contains that indication, the critical flag SHALL be
> set.

Now that looks quite dangerous to me.  A client that did not indicate
to understand the extension is indistinguishable from an simple
rfc2560 client.  And the simple rfc2560 should drop the OCSP response
with an unrecognized critical extension.  Which will either result
in the client to skip OCSP checking (bad) or to try other responders
or CRLs (also bad).
[Denis: An OCSP client which does not recognize a critical extension
within singleExtensions SHALL drop the individual response where that
critical extension is present but may accept other responses within
the field responses"]

What the (CAs) OCSP responder should answer depends on what the OCSP
responder wants the client/RP to do.  If the OCSP responder wants
the client/RP to *NOT* trust that cert, then "revoked (on hold)" is
the only sensible response.

[Denis: Again, if a critical extension is present within singleExtensions
in an individual response then the client SHALL drop the individual response
whatever the value of CertStatus may be. So it is irrelevant to argue
about the value of the CertStatus]

If the OCSP responder wants to include this information only for those
(new/updated) clients/RP that care about this info, then "good" with
a non-critical extension would be OK.

[Denis: No. See above]

"unknown" implies that the client/RP should ask someone else,
and a non-marginal number of client/RPs might skip the revocation
check when receiving an unknown response (treating it similar
to a network connection failure to the OCSP responder).

[Denis: No. See above]

> OCSP clients unable to process this singleResponse extension SHALL
> consider that the content of the single response
> cannot be interpreted (this is the usual way to process an extension that
> is marked critical) and this leads to an error
> case (e.g. single response content invalid).

This leads to the client/RP either skipping revocation or
falling back to CRL checking--where the "not issued" state can
not be conveyed at all.  I consider this behaviour non-sensical
with respect to the installed base.
[Denis: Compliant clients shall not skip revocation as you say.
However, your second argument is a valid consideration. I am preparing
a draft for the definition of a new extension within singleExtensions
and I have added the following note:

   NOTE: OCSP clients should not use a fallback mechanism based on CRLs
         when they encounter within singleExtensions an extension which
         is not understood and which is marked critical.]
 
> Clients able to process this singleResponse extension will know that the
> serial number of the certificate is not present
> in the list of the certificates issued by the CA to which the OCSP
> responder has access.

Client/RPs do not want to know that.  They instead want to know
"can I trust this cert"?  An OCSP server that says "This cert may have
not been issued" rather than "Do NOT trust this cert" is chickening out.

In order to make a whitelist check reasonably foolproof, the client/RP
should send either the whole cert or at least the certificate(!) hash
and the validity of the certificate in the OCSP request.
[Denis: In the draft I am preparing, the server may return the hash.
So you get the same property, but without the need to change the syntax
of the request. Note: the client may not know in advance whether the server
is using or not white lists]

The whitelist lookup should be performed with the certificate hash,
and the validity enables an OCSP responder to determine whether the
whitelist records it has access to are sufficiently "fresh" to
determine whether the cert in question has been issued.

[Denis: returning the hash provides the same benefit. The comparison
will be done by the client rather than by the server].

-Martin
--=_alternative 00290066C1257A60_=-- From tomas@primekey.se Mon Aug 20 01:04:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3931321F8661 for ; Mon, 20 Aug 2012 01:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUxQ2QrU+tS5 for ; Mon, 20 Aug 2012 01:04:50 -0700 (PDT) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3161B21F8621 for ; Mon, 20 Aug 2012 01:04:50 -0700 (PDT) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 65E9EE10D1 for ; Mon, 20 Aug 2012 10:04:48 +0200 (CEST) Received: from [192.168.3.193] (37-247-8-250.customers.ownit.se [37.247.8.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 4FE27E10C1 for ; Mon, 20 Aug 2012 10:04:48 +0200 (CEST) Message-ID: <5031EFA0.3020403@primekey.se> Date: Mon, 20 Aug 2012 10:04:48 +0200 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: pkix@ietf.org References: <20120818002502.9282E1A195@ld9781.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [pkix] Use of the OSCP unknown response, german CertHash extension? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 08:04:51 -0000 Of course some organizations have already started using extensions like some things discussed here. I'm pretty sure some of you are familiar with the german Common PKI. They have an OCSP extension (non critical): ----- Common PKI Profile: This Common PKI-specification defines the private single response extension CertHash that may deliver a positive statement about the availability of a certificate. (oid 1.3.36.8.3.13) SingleResponse extension: the responder may include this -- extension in a response to send the hash of the requested certificate to the requestor. This hash serves as evidence that the certificate is known to the responder (i.e. it is available in the queried directory) and will be used as means to provide a positive statement of availability. ----- While I am usually fiercly against extending standard protocols, this seems like one of the simplest ways to inform the client with extra information about what exactly is included in the "good" response. CAB Forum could use this possible information in a number of ways, including requiring that EV CAs include this or the cert will be rejected. The client is the end point enforcing a specific policy, and it seems to me that most OCSP consuming systems do not have a lot of random clients that interpret the responders responses in very different ways. For the browser world CAB Forum should be able to profile OCSP as to not require large changes to the spec. Cheers, Tomas On 08/20/2012 09:29 AM, denis.pinkas@bull.net wrote: > Martin, > > See my responses in the text below: > > > > > De : mrex@sap.com (Martin Rex) > A : denis.pinkas@bull.net > Cc : "Henry B. Hotz" , pkix > Date : 18/08/2012 02:25 > Objet : Re: [pkix] Use of the OSCP unknown response > ------------------------------------------------------------------------ > > > > Follow up of the previous mail on the same topic. > > > > There is a solution which does not use any extension in the request. > > Uh-oh! > > If the OCSP requestor does not indicate that it supports new response > semantics, then the OCSP responder can not distinguish rfc2560 clients > from updated clients! > > The prerequisite for any negotiation of new features is that > the request contains an indication about the clients additional > capabilities. Without it, the server should not be _extremely_ > conservative about changes in the response. > > *[Denis: No. The solution does not need any change in the request]* > > > This solution uses a new singleResponse extension, which indicates that > > the serial number of the certificate is not present > > in the list of the certificates issued by the CA to which the OCSP > > responder has access. > > > > When this extension contains that indication, the critical flag SHALL be > > set. > > Now that looks quite dangerous to me. A client that did not indicate > to understand the extension is indistinguishable from an simple > rfc2560 client. And the simple rfc2560 should drop the OCSP response > with an unrecognized critical extension. Which will either result > in the client to skip OCSP checking (bad) or to try other responders > or CRLs (also bad). > > *[Denis: An OCSP client which does not recognize a critical extension * > *within singleExtensions SHALL drop the individual response where that > critical extension is present but may accept other responses within > the field responses"]* > > What the (CAs) OCSP responder should answer depends on what the OCSP > responder wants the client/RP to do. If the OCSP responder wants > the client/RP to *NOT* trust that cert, then "revoked (on hold)" is > the only sensible response. > > *[Denis: Again, if a critical extension is present **within > singleExtensions > in an individual response then the client SHALL drop the individual > response * > *whatever the value of CertStatus may be. So it is irrelevant to argue * > *about the value of the CertStatus] * > > If the OCSP responder wants to include this information only for those > (new/updated) clients/RP that care about this info, then "good" with > a non-critical extension would be OK. > > *[Denis: No. See above]* > > "unknown" implies that the client/RP should ask someone else, > and a non-marginal number of client/RPs might skip the revocation > check when receiving an unknown response (treating it similar > to a network connection failure to the OCSP responder). > > *[Denis: No. See above]* > > > OCSP clients unable to process this singleResponse extension SHALL > > consider that the content of the single response > > cannot be interpreted (this is the usual way to process an extension > that > > is marked critical) and this leads to an error > > case (e.g. single response content invalid). > > This leads to the client/RP either skipping revocation or > falling back to CRL checking--where the "not issued" state can > not be conveyed at all. I consider this behaviour non-sensical > with respect to the installed base. > > *[Denis: Compliant clients shall not skip revocation as you say. * > *However, your second argument is a valid consideration. I am preparing * > *a draft for the definition of a new extension within singleExtensions * > *and I have added the following note:* > > * NOTE: OCSP clients should not use a fallback mechanism based on CRLs * > * when they encounter within singleExtensions an extension which * > * is not understood and which is marked critical.**]* > > > Clients able to process this singleResponse extension will know that the > > serial number of the certificate is not present > > in the list of the certificates issued by the CA to which the OCSP > > responder has access. > > Client/RPs do not want to know that. They instead want to know > "can I trust this cert"? An OCSP server that says "This cert may have > not been issued" rather than "Do NOT trust this cert" is chickening out. > > In order to make a whitelist check reasonably foolproof, the client/RP > should send either the whole cert or at least the certificate(!) hash > and the validity of the certificate in the OCSP request. > > *[Denis: In the draft I am preparing, the server may return the hash. * > *So you get the same property, but without the need to change the syntax * > *of the request. Note: the client may not know in advance whether the > server * > *is using or not white lists]* > > The whitelist lookup should be performed with the certificate hash, > and the validity enables an OCSP responder to determine whether the > whitelist records it has access to are sufficiently "fresh" to > determine whether the cert in question has been issued. > > *[Denis: returning the hash provides the same benefit. The comparison * > *will be done by the client rather than by the server].* > > -Martin > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From denis.pinkas@bull.net Mon Aug 20 01:27:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C96221F86BB for ; Mon, 20 Aug 2012 01:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptrUXXyh-fMw for ; Mon, 20 Aug 2012 01:27:27 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id C210621F86B8 for ; Mon, 20 Aug 2012 01:27:26 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id E60FD18165; Mon, 20 Aug 2012 10:27:25 +0200 (CEST) In-Reply-To: <5031EFA0.3020403@primekey.se> References: <20120818002502.9282E1A195@ld9781.wdf.sap.corp> <5031EFA0.3020403@primekey.se> To: Tomas Gustavsson MIME-Version: 1.0 X-KeepSent: 6EB8ECFD:0DA80AF0-C1257A60:002D821B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Mon, 20 Aug 2012 10:27:23 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 20/08/2012 10:27:25, Serialize complete at 20/08/2012 10:27:25 Content-Type: multipart/alternative; boundary="=_alternative 002E6F5AC1257A60_=" Cc: pkix@ietf.org Subject: Re: [pkix] Use of the OSCP unknown response, german CertHash extension? X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 08:27:28 -0000 Message en plusieurs parties au format MIME --=_alternative 002E6F5AC1257A60_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tomas, Thank you for the information, However, this extension does not help if the OCSP client does not=20 understand it,=20 since it is a non critical extension. I am preparing a draft for an extension which provides benefits in both=20 situations,=20 i.e. whether the OCSP client understands it or whether it does not.=20 Of course, the benefits are exactly not the same. Denis De : Tomas Gustavsson A : pkix@ietf.org Date : 20/08/2012 10:04 Objet : Re: [pkix] Use of the OSCP unknown response, german CertHash=20 extension? Envoy=E9 par : pkix-bounces@ietf.org Of course some organizations have already started using extensions like=20 some things discussed here. I'm pretty sure some of you are familiar with the german Common PKI.=20 They have an OCSP extension (non critical): ----- Common PKI Profile: This Common PKI-specification defines the private=20 single response extension CertHash that may deliver a positive statement=20 about the availability of a certificate. (oid 1.3.36.8.3.13) SingleResponse extension: the responder may include this -- extension in a response to send the hash of the requested certificate to the requestor. This hash serves as evidence that the certificate is known to the responder (i.e. it is available in the queried directory) and will be used as means to provide a positive statement of availability. ----- While I am usually fiercly against extending standard protocols, this=20 seems like one of the simplest ways to inform the client with extra=20 information about what exactly is included in the "good" response. CAB Forum could use this possible information in a number of ways,=20 including requiring that EV CAs include this or the cert will be rejected. The client is the end point enforcing a specific policy, and it seems to=20 me that most OCSP consuming systems do not have a lot of random clients=20 that interpret the responders responses in very different ways. For the browser world CAB Forum should be able to profile OCSP as to not=20 require large changes to the spec. Cheers, Tomas On 08/20/2012 09:29 AM, denis.pinkas@bull.net wrote: > Martin, > > See my responses in the text below: > > > > > De : mrex@sap.com (Martin Rex) > A : denis.pinkas@bull.net > Cc : "Henry B. Hotz" , pkix > Date : 18/08/2012 02:25 > Objet : Re: [pkix] Use of the OSCP unknown response > ------------------------------------------------------------------------ > > > > Follow up of the previous mail on the same topic. > > > > There is a solution which does not use any extension in the request. > > Uh-oh! > > If the OCSP requestor does not indicate that it supports new response > semantics, then the OCSP responder can not distinguish rfc2560 clients > from updated clients! > > The prerequisite for any negotiation of new features is that > the request contains an indication about the clients additional > capabilities. Without it, the server should not be =5Fextremely=5F > conservative about changes in the response. > > *[Denis: No. The solution does not need any change in the request]* > > > This solution uses a new singleResponse extension, which indicates=20 that > > the serial number of the certificate is not present > > in the list of the certificates issued by the CA to which the OCSP > > responder has access. > > > > When this extension contains that indication, the critical flag SHALL = be > > set. > > Now that looks quite dangerous to me. A client that did not indicate > to understand the extension is indistinguishable from an simple > rfc2560 client. And the simple rfc2560 should drop the OCSP response > with an unrecognized critical extension. Which will either result > in the client to skip OCSP checking (bad) or to try other responders > or CRLs (also bad). > > *[Denis: An OCSP client which does not recognize a critical extension * > *within singleExtensions SHALL drop the individual response where that > critical extension is present but may accept other responses within > the field responses"]* > > What the (CAs) OCSP responder should answer depends on what the OCSP > responder wants the client/RP to do. If the OCSP responder wants > the client/RP to *NOT* trust that cert, then "revoked (on hold)" is > the only sensible response. > > *[Denis: Again, if a critical extension is present **within > singleExtensions > in an individual response then the client SHALL drop the individual > response * > *whatever the value of CertStatus may be. So it is irrelevant to argue * > *about the value of the CertStatus] * > > If the OCSP responder wants to include this information only for those > (new/updated) clients/RP that care about this info, then "good" with > a non-critical extension would be OK. > > *[Denis: No. See above]* > > "unknown" implies that the client/RP should ask someone else, > and a non-marginal number of client/RPs might skip the revocation > check when receiving an unknown response (treating it similar > to a network connection failure to the OCSP responder). > > *[Denis: No. See above]* > > > OCSP clients unable to process this singleResponse extension SHALL > > consider that the content of the single response > > cannot be interpreted (this is the usual way to process an extension > that > > is marked critical) and this leads to an error > > case (e.g. single response content invalid). > > This leads to the client/RP either skipping revocation or > falling back to CRL checking--where the "not issued" state can > not be conveyed at all. I consider this behaviour non-sensical > with respect to the installed base. > > *[Denis: Compliant clients shall not skip revocation as you say. * > *However, your second argument is a valid consideration. I am preparing=20 * > *a draft for the definition of a new extension within singleExtensions * > *and I have added the following note:* > > * NOTE: OCSP clients should not use a fallback mechanism based on CRLs = * > * when they encounter within singleExtensions an extension which = * > * is not understood and which is marked critical.**]* > > > Clients able to process this singleResponse extension will know that=20 the > > serial number of the certificate is not present > > in the list of the certificates issued by the CA to which the OCSP > > responder has access. > > Client/RPs do not want to know that. They instead want to know > "can I trust this cert"? An OCSP server that says "This cert may have > not been issued" rather than "Do NOT trust this cert" is chickening out. > > In order to make a whitelist check reasonably foolproof, the client/RP > should send either the whole cert or at least the certificate(!) hash > and the validity of the certificate in the OCSP request. > > *[Denis: In the draft I am preparing, the server may return the hash. * > *So you get the same property, but without the need to change the syntax = * > *of the request. Note: the client may not know in advance whether the > server * > *is using or not white lists]* > > The whitelist lookup should be performed with the certificate hash, > and the validity enables an OCSP responder to determine whether the > whitelist records it has access to are sufficiently "fresh" to > determine whether the cert in question has been issued. > > *[Denis: returning the hash provides the same benefit. The comparison * > *will be done by the client rather than by the server].* > > -Martin > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 002E6F5AC1257A60_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Tomas,

Thank you for the information,

However, this extension does not help if the OCSP client does not understand it,
since it is a non critical extension.

I am preparing a draft for an extens= ion which provides benefits in both situations,
i.e. whether the OCSP client underst= ands it or whether it does not.
Of course, the benefits are exactly not the same.

Denis



De :     &= nbsp;  Tomas Gustavsson <tomas@= primekey.se>
A :     &n= bsp;  pkix@ietf.org
Date :    =    20/08/2012 10:04
Objet :        Re: [pkix] Use of the OSCP unknown response,        german CertHash extension?
Envoy=E9 par :  = ;      pkix-bounces@ietf.or= g




Of course some organizations have already started using extensions like
some things discussed here.

I'm pretty sure some of you are familiar with the german Common PKI.
They have an OCSP extension (non critical):

-----
Common PKI Profile: This Common PKI-specification defines the private
single response extension CertHash that may deliver a positive statement
about the availability
of a certificate.

(oid 1.3.36.8.3.13)

SingleResponse extension: the responder may include this --
extension in a response to send the hash of the requested
certificate to the requestor. This hash serves as evidence that
the certificate is known to the responder (i.e. it is available in
the queried directory) and will be used as means to provide a
positive statement of availability.
-----

While I am usually fiercly against extending standard protocols, this
seems like one of the simplest ways to inform the client with extra
information about what exactly is included in the "good" response= .

CAB Forum could use this possible information in a number of ways,
including requiring that EV CAs include this or the cert will be rejected.<= br>
The client is the end point enforcing a specific policy, and it seems to
me that most OCSP consuming systems do not have a lot of random clients
that interpret the responders responses in very different ways.
For the browser world CAB Forum should be able to profile OCSP as to not
require large changes to the spec.

Cheers,
Tomas


On 08/20/2012 09:29 AM, denis.pinkas@bull.net wrote:
> Martin,
>
> See my responses in the text below:
>
>
>
>
> De : mrex@sap.com (Martin Rex)
> A : denis.pinkas@bull.net
> Cc : "Henry B. Hotz" <hotz@jpl.nasa.gov>, pkix <pki= x@ietf.org>
> Date : 18/08/2012 02:25
> Objet : Re: [pkix] Use of the OSCP unknown response
> ----------------------------------------------------------------------= --
>
>
>  > Follow up of the previous mail on the same topic.
>  >
>  > There is a solution which does not use any extension in the request.
>
> Uh-oh!
>
> If the OCSP requestor does not indicate that it supports new response<= br> > semantics, then the OCSP responder can not distinguish rfc2560 clients=
> from updated clients!
>
> The prerequisite for any negotiation of new features is that
> the request contains an indication about the clients additional
> capabilities.  Without it, the server should not be =5Fextremely= =5F
> conservative about changes in the response.
>
> *[Denis: No. The solution does not need any change in the request]*
>
>  > This solution uses a new singleResponse extension, which indicates that
>  > the serial number of the certificate is not present
>  > in the list of the certificates issued by the CA to which the OCSP
>  > responder has access.
>  >
>  > When this extension contains that indication, the critical flag SHALL be
>  > set.
>
> Now that looks quite dangerous to me.  A client that did not indicate
> to understand the extension is indistinguishable from an simple
> rfc2560 client.  And the simple rfc2560 should drop the OCSP response
> with an unrecognized critical extension.  Which will either resul= t
> in the client to skip OCSP checking (bad) or to try other responders > or CRLs (also bad).
>
> *[Denis: An OCSP client which does not recognize a critical extension *
> *within singleExtensions SHALL drop the individual response where that
> critical extension is present but may accept other responses within
> the field responses"]*
>
> What the (CAs) OCSP responder should answer depends on what the OCSP > responder wants the client/RP to do.  If the OCSP responder wants=
> the client/RP to *NOT* trust that cert, then "revoked (on hold)&q= uot; is
> the only sensible response.
>
> *[Denis: Again, if a critical extension is present **within
> singleExtensions
> in an individual response then the client SHALL drop the individual
> response *
> *whatever the value of CertStatus may be. So it is irrelevant to argue *
> *about the value of the CertStatus] *
>
> If the OCSP responder wants to include this information only for those=
> (new/updated) clients/RP that care about this info, then "good&qu= ot; with
> a non-critical extension would be OK.
>
> *[Denis: No. See above]*
>
> "unknown" implies that the client/RP should ask someone else,
> and a non-marginal number of client/RPs might skip the revocation
> check when receiving an unknown response (treating it similar
> to a network connection failure to the OCSP responder).
>
> *[Denis: No. See above]*
>
>  > OCSP clients unable to process this singleResponse extension SHALL
>  > consider that the content of the single response
>  > cannot be interpreted (this is the usual way to process an extension
> that
>  > is marked critical) and this leads to an error
>  > case (e.g. single response content invalid).
>
> This leads to the client/RP either skipping revocation or
> falling back to CRL checking--where the "not issued" state can
> not be conveyed at all.  I consider this behaviour non-sensical > with respect to the installed base.
>
> *[Denis: Compliant clients shall not skip revocation as you say. *
> *However, your second argument is a valid consideration. I am preparing *
> *a draft for the definition of a new extension within singleExtensions *
> *and I have added the following note:*
>
> *   NOTE: OCSP clients should not use a fallback mechanism based on CRLs *
> *         when they encounter within singleExtensi= ons an extension which *
> *         is not understood and which is marked critical.**]*
>
>  > Clients able to process this singleResponse extension will know that the
>  > serial number of the certificate is not present
>  > in the list of the certificates issued by the CA to which the OCSP
>  > responder has access.
>
> Client/RPs do not want to know that.  They instead want to know > "can I trust this cert"?  An OCSP server that says "This cert may have
> not been issued" rather than "Do NOT trust this cert" is chickening out.
>
> In order to make a whitelist check reasonably foolproof, the client/RP=
> should send either the whole cert or at least the certificate(!) hash<= br> > and the validity of the certificate in the OCSP request.
>
> *[Denis: In the draft I am preparing, the server may return the hash. *
> *So you get the same property, but without the need to change the syntax *
> *of the request. Note: the client may not know in advance whether the
> server *
> *is using or not white lists]*
>
> The whitelist lookup should be performed with the certificate hash,
> and the validity enables an OCSP responder to determine whether the
> whitelist records it has access to are sufficiently "fresh" to
> determine whether the cert in question has been issued.
>
> *[Denis: returning the hash provides the same benefit. The comparison *
> *will be done by the client rather than by the server].*
>
> -Martin
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> pkix mailing list
> pkix@ietf.org
> <= font size=3D2>https://www.ietf.org/mailman/listinfo/pkix
>

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--=_alternative 002E6F5AC1257A60_=-- From mrex@sap.com Mon Aug 20 04:46:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F3E21F861E for ; Mon, 20 Aug 2012 04:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.172 X-Spam-Level: X-Spam-Status: No, score=-10.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPcTyhtWhWE4 for ; Mon, 20 Aug 2012 04:46:03 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7774721F862B for ; Mon, 20 Aug 2012 04:46:02 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q7KBjqZM020491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Aug 2012 13:45:53 +0200 (MEST) In-Reply-To: To: denis.pinkas@bull.net Date: Mon, 20 Aug 2012 13:45:52 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120820114552.803851A196@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 11:46:04 -0000 denis.pinkas@bull.net wrote: > > If the OCSP requestor does not indicate that it supports new response > semantics, then the OCSP responder can not distinguish rfc2560 clients > from updated clients! > > The prerequisite for any negotiation of new features is that > the request contains an indication about the clients additional > capabilities. Without it, the server should not be _extremely_ > conservative about changes in the response. > > [Denis: No. The solution does not need any change in the request] Oh yes, you do. That requirement is described in rfc2560 section 4.4.3. http://tools.ietf.org/html/rfc2560#section-4.4.3 An OCSP server is not allowed to return something other than a basic ocsp response unless the client has included a requestExtension that indicates that the client recognizes other than id-pkix-ocsp-basic. > > > This solution uses a new singleResponse extension, which indicates that > > the serial number of the certificate is not present > > in the list of the certificates issued by the CA to which the OCSP > > responder has access. > > > > When this extension contains that indication, the critical flag SHALL be > > > set. > > Now that looks quite dangerous to me. A client that did not indicate > to understand the extension is indistinguishable from an simple > rfc2560 client. And the simple rfc2560 should drop the OCSP response > with an unrecognized critical extension. Which will either result > in the client to skip OCSP checking (bad) or to try other responders > or CRLs (also bad). > > [Denis: An OCSP client which does not recognize a critical extension > within singleExtensions SHALL drop the individual response where that > critical extension is present but may accept other responses within > the field responses"] I would not be surprised if a client that obtains a response for an request about a singular cert would drop the entire response if it contained an unexpected (=non-negotiated) critical responseExtension in the first single response. I would consider it strange if an OCSP response about a singular cert contains multiple single repsonses about the exact same cert with different properties (one with a critical extension, and one without a critical extension). Since there is no specific ordering defined for processing multiple single responses for one singular cert in rfc2560, a response with multiple responses for a singular cert would be a clear violation of the protocol defined rfc2560. > > OCSP clients unable to process this singleResponse extension SHALL > > consider that the content of the single response > > cannot be interpreted (this is the usual way to process an extension > > that is marked critical) and this leads to an error > > case (e.g. single response content invalid). > > This leads to the client/RP either skipping revocation or > falling back to CRL checking--where the "not issued" state can > not be conveyed at all. I consider this behaviour non-sensical > with respect to the installed base. > > [Denis: Compliant clients shall not skip revocation as you say. > However, your second argument is a valid consideration. I am preparing > a draft for the definition of a new extension within singleExtensions > and I have added the following note: > > NOTE: OCSP clients should not use a fallback mechanism based on CRLs > when they encounter within singleExtensions an extension which > is not understood and which is marked critical.] You can not change behaviour of the installed base by adding a note to a protocol update. The only thing you can reliably affect is the behaviour of *NEW* implementations, and a hard-to-predict subset of the installed base when it is patched. > > The whitelist lookup should be performed with the certificate hash, > and the validity enables an OCSP responder to determine whether the > whitelist records it has access to are sufficiently "fresh" to > determine whether the cert in question has been issued. > > [Denis: returning the hash provides the same benefit. The comparison > will be done by the client rather than by the server]. As someone regular doing customer support, I strongly dislike the reverse approach. This is an issue where it would be quite sensible to require the client to send the certificate hash, so that the CA can detect when there is a problem, and CA helpdesk has access to that information when the cert hash mismatch leads to clients/RPs failing authentication--rather than having to jump hoops in order to trace arbitrary third-party software for reasons why it keeps failing cert revocation checks. The client can use the best/strongest hash available, whereas the server would have to use the weakest (when the client did not convey anything through extensions about its capabilities. -Martin From hallam@gmail.com Mon Aug 20 09:24:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FFF21F86DC for ; Mon, 20 Aug 2012 09:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.491 X-Spam-Level: X-Spam-Status: No, score=-5.491 tagged_above=-999 required=5 tests=[AWL=-1.892, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG0sWjOpBJ2p for ; Mon, 20 Aug 2012 09:24:44 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02F5521F86AD for ; Mon, 20 Aug 2012 09:24:43 -0700 (PDT) Received: by yhq56 with SMTP id 56so5714079yhq.31 for ; Mon, 20 Aug 2012 09:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8bsN46QjuImkTZwu7/hPaGoTjHS2Y9yaheUxqM8ylIU=; b=lG4K2aKTZvi8EAG6DUErKTqbtxe+BxvFHEp0SUwnpAF1rcwIMOnW63YlYH09Na9CO2 WjC8MRUWzxnn9+Xk68hBovPkBD4yYezMI+LAbyuxon06p2W/T6N4DCm0FDhCy+4Q9uZ8 EMA1ItbxxAP/5dvuiwibmu96W40sGXZzz4lMbfEfY3iHdNk2aquow91PEvPTQNEzx1JU Mcc+fKunQ1N2NJ3D5Svz7mPYjkRJmRlkH+dIKz5X/WzgxvkleXLv/iD1VLKILBp5O5oU WJSV2ArdVR+8jLe/1dbLJT2y9z6gdY7H3in9zyXoZ6Q+pqkLQ7hgFybPbQYVlDo4VIr2 48bQ== MIME-Version: 1.0 Received: by 10.60.172.236 with SMTP id bf12mr10657964oec.23.1345479883504; Mon, 20 Aug 2012 09:24:43 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Mon, 20 Aug 2012 09:24:43 -0700 (PDT) In-Reply-To: References: <20120818002502.9282E1A195@ld9781.wdf.sap.corp> Date: Mon, 20 Aug 2012 12:24:43 -0400 Message-ID: From: Phillip Hallam-Baker To: denis.pinkas@bull.net Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 16:24:44 -0000 I don't think what we actually do here matters at all provided that (1) we all interpret the same signals to mean the same thing and (2) we can actually distinguish between the status situations that require it. The fact that OCSP does not distinguish 'good' from 'utterly bad' has turned out to be a very bad thing in practice. One problem here is that OCSP was saddled with being both an authoritative status protocol and a non-authoritative one without the use cases for either being adequately considered let alone separated. What is in the specification does not really worry me a whole lot at this point. What I personally care about is what the code that is out there in the wild does. It seems to me to be completely sensible for an authoritative OCSP responder to report status as follows: Good: I know that this is good Revoked: This was once good but now is bad Unknown: This is so bad I ain't ever heard of it. Likewise it seems completely sensible for a non-authoritative OCSP responder to report status as Good: I have CRLs for that issuer and it is not on it Revoked: It is on the CRL for that issuer I have Unknown: I do not have a CRL for that issuer. These seem to be completely separate semantics that have been unfortunately merged into one spec in a bad fashion. How does the client know that the responder is authoritative or not? Well how did it decide to send the query there in the first place? If the responder was found by following a URL in the cert then it is authoritative. Otherwise the responder must have been configured out of band and that configuration should have the necessary information. An authoritative response should hopefully have some common connection to the trust anchor for the cert, The question is how we get from where we are now to where we want to be given the deployed infrastructure. If the criticality flag hack proposed by Denis turns out to be more backwards compatible then we should probably do that, if it turns out that real deployed clients treat an OCSP token with a criticality flag as 'accept the cert' then we should not. In any case I think we really do need to have a set of extensions to OCSP that allow a CA to state with clarity: 1) This OCSP response purports to be from the authoritative provider of status for that cert 2) Which specific certificate the response refers to 3) Whether the certificate was issued and if issued what its status is The fact that we appear to be having difficulty with all three points here does not lead me to conclude 'do what the spec says regardless of whether it makes sense'. From mrex@sap.com Mon Aug 20 11:52:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1E11E8091 for ; Mon, 20 Aug 2012 11:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWXEaAVCbnoF for ; Mon, 20 Aug 2012 11:52:31 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5723311E808E for ; Mon, 20 Aug 2012 11:52:29 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7KIqM8E012330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Aug 2012 20:52:27 +0200 (MEST) In-Reply-To: To: Phillip Hallam-Baker Date: Mon, 20 Aug 2012 20:52:22 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120820185222.50D5A1A198@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:52:33 -0000 Phillip Hallam-Baker wrote: > > I don't think what we actually do here matters at all provided that > (1) we all interpret the same signals to mean the same thing and (2) > we can actually distinguish between the status situations that require > it. > > The fact that OCSP does not distinguish 'good' from 'utterly bad' has > turned out to be a very bad thing in practice. The originial protocol failed to recognized (from the discussion of "good" in rfc2560 section 2.2) that there is a need for bad status codes besides revoked. But by lacking to define other states from the start, the only reasonable way forward is to use "revoked" to convey all variations of known "bad", and to sort out the details through extensions. It seems silly to have an OCSP responder label a known "bad" certificate "good" or likewise to chicken out with an "unknown" reply, which will cause RPs to ignore the result or fallback to CRL checking (and the latter will result in a "good" classification of "bad" states that a CRL can not represent). A "fallback to other OCSP server" would be even more silly, because if the other OCSP server would return "good" or "bad", then the first OCSP server should have provided this answer in the first place. And if the other OCSP server also provides "unknown", then it is an obvious waste of resources, ultimately ending in the RP attempting CRL-checking (with a result of "good"), or skipping revocation checking entirely. Adding situations where OCSP-based revocation will fail to provide an answer (i.e. "unknown" rather than "good" or "bad/revoked") will make hard fail clients/RP further unlikely. > > > One problem here is that OCSP was saddled with being both an > authoritative status protocol and a non-authoritative one without the > use cases for either being adequately considered let alone separated. > > How does the client know that the responder is authoritative or not? Authoritative is exclusively indicated by rfc2560 section 4.2.2.2 items (2) and (3). http://tools.ietf.org/html/rfc2560#section-4.2.2.2 2. Is the certificate of the CA that issued the certificate in question; or 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate in question." > > An authoritative response should hopefully have some common connection > to the trust anchor for the cert, Ouch. The "common trust anchor" is a security vulerability in the definition of authorized CRL signers! rfc2560 originally does not have this vulnerability, and I strongly opposed to drilling the CRL security hole into the OCSP spec. > > Well how did it decide to send the query there in the first place? If > the responder was found by following a URL in the cert then it is > authoritative. Otherwise the responder must have been configured out Strong disagree. It is *completely* irrelevant how the OCSP response was actually obtained (from cache, stapled in a TLS extension, out-of-band, proxied by a local OCSP responder, etc.). > > What is in the specification does not really worry me a whole lot at > this point. What I personally care about is what the code that is out > there in the wild does. But looking only at the behaviour of the well-known browser vendors would be short-sighted. The question is: which of the well-defined behaviour (per rfc2560) works in a predictable fashion in the installed base. The behaviour resulting from an "unknown" response of the OCSP responder is de-facto undefined. > > It seems to me to be completely sensible for an authoritative OCSP > responder to report status as follows: > > Good: I know that this is good > Revoked: This was once good but now is bad > Unknown: This is so bad I ain't ever heard of it. That latter unkown state does not exist in rfc2560. The end of rfc2560, section 2.2 Response says exactly this: The "unknown" state indicates that the responder doesn't know about the certificate being requested. Which means that the "unknown" response clearly means that the OCSP server does either not know about the status or does not want to answer, with the effective meaning of "Don't ask ME, ask someone else." It certainly does NOT say "worse than revoked". > > Likewise it seems completely sensible for a non-authoritative OCSP > responder to report status as > > Good: I have CRLs for that issuer and it is not on it > Revoked: It is on the CRL for that issuer I have > Unknown: I do not have a CRL for that issuer. Where does rfc2560 _limit_ the information source for the answers of non-authoritative OCSP responders to CRLs? The description for the "good" state is very explicit that OCSP responders may work on other information resources besides CRLs. (there would not be much of an extensibility, if it didn't). -Martin From mrex@sap.com Mon Aug 20 14:19:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB6021F852A for ; Mon, 20 Aug 2012 14:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.175 X-Spam-Level: X-Spam-Status: No, score=-10.175 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kt5B6inzk1u6 for ; Mon, 20 Aug 2012 14:19:18 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E548621F8505 for ; Mon, 20 Aug 2012 14:19:17 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7KLJF3g022203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Aug 2012 23:19:15 +0200 (MEST) In-Reply-To: <501A927A.7050308@nist.gov> To: "David A. Cooper" Date: Mon, 20 Aug 2012 23:19:15 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120820211915.53CB01A198@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5280bis, Section 3.2) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 21:19:18 -0000 David A. Cooper wrote: > > I don't know why you find the example "thoroughly confusing" or "a bad > idea in general," but if you think this is such a bad example, what > would you propose as a good example of a locally trusted OCSP responder? It is completely out-of-scope for PKIX/rfc5280 how to handle a locally trusted OCSP responder cert that is a self-signed non-CA cert with respect to validating that cert, revoking such a cert and (re-)distributing an update to such a cert. I believe that creating an example, which is out-of-scope for PKIX in so many ways, to be a bad idea in general. Personally, I believe that a local OCSP responder is an idea that is not well thought out, because it does not appear to fit with PKIX (in-scope) protocol features at all. How to identify whether a signer is a "trusted local OCSP signer", and how to configure for which CAs it is trusted to provide revocation info looks quite complicated to me. Is it documented somewhere how you would configure this for e.g. Microsoft Windows? -Martin From david.cooper@nist.gov Mon Aug 20 15:18:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F5821F8557 for ; Mon, 20 Aug 2012 15:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTM05niWrzKU for ; Mon, 20 Aug 2012 15:18:18 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8645121F854D for ; Mon, 20 Aug 2012 15:18:17 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 20 Aug 2012 18:17:50 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.379.0; Mon, 20 Aug 2012 18:17:52 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q7KMHrRQ014943; Mon, 20 Aug 2012 18:17:54 -0400 Message-ID: <5032B791.60204@nist.gov> Date: Mon, 20 Aug 2012 18:17:53 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120723 Thunderbird/14.0 MIME-Version: 1.0 To: "mrex@sap.com" References: <20120820211915.53CB01A198@ld9781.wdf.sap.corp> In-Reply-To: <20120820211915.53CB01A198@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix Subject: Re: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5280bis, Section 3.2) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 22:18:19 -0000 This just seems to be a long-winded way of saying that you don't have a good example of a locally trusted OCSP responder because you don't like the idea. Well, whether you like it or not, locally trusted OCSP responders are explicitly permitted by RFC 2560. I also totally disagree with your implication that it is unacceptable to include an example of a locally trusted OCSP responder in which the responder's key is distributed in the form of a self-signed certificate. The 5280 update document states that self-signed certificates that are issued by other than CAs are outside the scope of RFC 5280 (not PKIX). It does not say that such certificates cannot be used as an example in a PKIX document. Furthermore, the example that you disagree with does not specify "how to handle" the self-signed certificate, it simply indicates in the figure that the responder's public key appears in a self-signed certificate. Neither does the example provide any details about how to configure a client to work with a locally trusted OCSP responder. On 08/20/2012 05:19 PM, Martin Rex wrote: > David A. Cooper wrote: >> I don't know why you find the example "thoroughly confusing" or "a bad >> idea in general," but if you think this is such a bad example, what >> would you propose as a good example of a locally trusted OCSP responder? > It is completely out-of-scope for PKIX/rfc5280 how to handle > a locally trusted OCSP responder cert that is a self-signed non-CA cert > with respect to validating that cert, revoking such a cert and > (re-)distributing an update to such a cert. > > I believe that creating an example, which is out-of-scope for PKIX > in so many ways, to be a bad idea in general. > > Personally, I believe that a local OCSP responder is an idea that is > not well thought out, because it does not appear to fit with PKIX > (in-scope) protocol features at all. > > How to identify whether a signer is a "trusted local OCSP signer", > and how to configure for which CAs it is trusted to provide > revocation info looks quite complicated to me. Is it documented > somewhere how you would configure this for e.g. Microsoft Windows? > > > -Martin > . > From mrex@sap.com Mon Aug 20 16:01:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF6621F8557 for ; Mon, 20 Aug 2012 16:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.176 X-Spam-Level: X-Spam-Status: No, score=-10.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXdnbX4Da8AS for ; Mon, 20 Aug 2012 16:01:09 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D1B2D21F8555 for ; Mon, 20 Aug 2012 16:01:08 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7KN118i003252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Aug 2012 01:01:06 +0200 (MEST) In-Reply-To: <5032B791.60204@nist.gov> To: "David A. Cooper" Date: Tue, 21 Aug 2012 01:01:01 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120820230101.565311A198@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5280bis, Section 3.2) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 23:01:09 -0000 David A. Cooper wrote: > > This just seems to be a long-winded way of saying that you don't have a > good example of a locally trusted OCSP responder because you don't like > the idea. I'm not aware of any reasonable local OCSP responder scenario, any I have serious doubts that it exists at all. Prove me wrong. > > Well, whether you like it or not, locally trusted OCSP responders are > explicitly permitted by RFC 2560. I agree that they're mentioned. But they're so extremely underspecified, that I violently disagree that rfc2560 supports "local OCSP responders" in any remotely meaningful fashion (read: in a fashion that allows independent interoperable implementations). > > I also totally disagree with your > implication that it is unacceptable to include an example of a locally > trusted OCSP responder in which the responder's key is distributed in > the form of a self-signed certificate. rfc2560 contains a paragraph that is extremely explicit that it might be dangerous to have an OCSP signer cert for ONE SINGLE CA that is non-revocable: http://tools.ietf.org/html/rfc2560#section-4.2.2.2.1 - A CA may specify that an OCSP client can trust a responder for the lifetime of the responder's certificate. The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension. The value of the extension should be NULL. CAs issuing such a certificate should realized that a compromise of the responder's key, is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CA's may choose to issue this type of certificate with a very short lifetime and renew it frequently. a self-signed local OCSP signer cert is a non-revocable, lifetime-unlimited, OCSP signer cert valid for *ALL* CAs. On my scorecards, this makes it the most irresponsible fashion to configure rfc2560, because it is the most extreme opposite of what is suggested in the paragraph quoted above. Therefore I'm stronly opposed to add to the spec an example of a local OCSP responder using a self-signed non-CA cert. > > The 5280 update document states > that self-signed certificates that are issued by other than CAs are > outside the scope of RFC 5280 (not PKIX). I'm unfamiliar to the definition of the term "PKIX" that you're using. Self-signed certificates from non-CA entities are outside of scope for both, ITU-T X.509 and the "PKIX Certificate and CRL Profile" http://tools.ietf.org/html/rfc5280#section-3 Following is a simplified view of the architectural model assumed by the Public-Key Infrastructure using X.509 (PKIX) specifications. > > It does not say that such > certificates cannot be used as an example in a PKIX document. I'm sorry, but I find it somewhat strange that an example description for how to use an OCSP protocol feature for PKIX is completely out of scope for PKIX. Either there is a way to create a reasonable, comparatively simple and fully in-scope example usage for a local OCSP responder, or that feature should be pruned from the protocol. That is what is _supposed_ to happen when a document progresses on the maturity level of IETF standards. -Martin From peter.sylvester@edelweb.fr Tue Aug 21 01:34:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FB321F86B4 for ; Tue, 21 Aug 2012 01:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEA6R6gRwgu1 for ; Tue, 21 Aug 2012 01:34:55 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 62E7021F86A2 for ; Tue, 21 Aug 2012 01:34:55 -0700 (PDT) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id 327BF5E0A1 for ; Tue, 21 Aug 2012 10:34:54 +0200 (CEST) Received: from mail1.on-x.com (mail1.on-x.com [192.168.10.66]) by mx1.on-x.com (Postfix) with ESMTP id 1E5FB5E09D for ; Tue, 21 Aug 2012 10:34:54 +0200 (CEST) Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id 20C415E30A for ; Tue, 21 Aug 2012 10:34:55 +0200 (CEST) Received: from smtps.on-x.com (unknown [192.168.14.66]) by mail1.on-x.com (Postfix) with ESMTP id 14CC25E309 for ; Tue, 21 Aug 2012 10:34:55 +0200 (CEST) Received: from [192.168.0.27] (unknown [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id F34605E288 for ; Tue, 21 Aug 2012 10:34:53 +0200 (CEST) Message-ID: <5033482C.4070602@edelweb.fr> Date: Tue, 21 Aug 2012 10:34:52 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: pkix@ietf.org References: <20120820230101.565311A198@ld9781.wdf.sap.corp> In-Reply-To: <20120820230101.565311A198@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5280bis, Section 3.2) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 08:34:56 -0000 On 08/21/2012 01:01 AM, Martin Rex wrote: > David A. Cooper wrote: >> This just seems to be a long-winded way of saying that you don't have a >> good example of a locally trusted OCSP responder because you don't like >> the idea. > I'm not aware of any reasonable local OCSP responder scenario, any > I have serious doubts that it exists at all. Prove me wrong. an application delegates all validation to a dedicated validation authority which is managed by a security staff. a local ocsp responder implements company wide or personal trust policies and allows to manage them independently from applications. From DPKemp@missi.ncsc.mil Tue Aug 21 06:28:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89AE21F8643 for ; Tue, 21 Aug 2012 06:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-27cyhC5WBw for ; Tue, 21 Aug 2012 06:28:35 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9119321F8619 for ; Tue, 21 Aug 2012 06:28:35 -0700 (PDT) Received: from clavin.missi.ncsc.mil (clavin.missi.ncsc.mil [144.51.60.17]) by stingray.missi.ncsc.mil with ESMTP id q7LDSXeW046474 for ; Tue, 21 Aug 2012 09:28:33 -0400 (EDT) Received: from odysseus.missi.ncsc.mil (144.51.60.172) by clavin.missi.ncsc.mil (144.51.60.17) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Aug 2012 09:28:33 -0400 Received: from clavin.missi.ncsc.mil ([144.51.60.17]) by odysseus.missi.ncsc.mil ([144.51.60.172]) with mapi id 14.01.0355.002; Tue, 21 Aug 2012 09:28:33 -0400 From: "Kemp, David P." To: "pkix@ietf.org" Thread-Topic: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5280bis, Section 3.2) Thread-Index: AQHNfxl9YAahaiG/ZUai3wSOKGNUDZdjiCOAgAAMDYCAAKBVAIAACx9w Date: Tue, 21 Aug 2012 13:28:32 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8216F8A28@clavin.missi.ncsc.mil> References: <20120820230101.565311A198@ld9781.wdf.sap.corp> <5033482C.4070602@edelweb.fr> In-Reply-To: <5033482C.4070602@edelweb.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.54.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5280bis, Section 3.2) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 13:28:36 -0000 +1. Doesn't corporate IT staff retain (at least in principle) the authority to = accept OS and application updates from manufacturers, vet them for compatib= ility with the local environment, and only then push them to the desktop? = In some cases it may just be a rubber stamp (who has the time to keep up wi= th the flood), but the ability is there. The PKI is responsible for supporting authentication; the local enterprise = is responsible for authorization. In cases where the authorization infrast= ructure is immature or nonexistent, local managers may wish to revoke the a= uthentication credentials of someone as their desk is being cleaned out and= they are escorted out the door, and the PKI may not be able to respond in = the desired timeframe. That may be an extreme example, but there are scena= rios where authentication is used as a blunt instrument in lieu of proper a= uthorization. Local OCSP is a method of implementing that blunt instrument= . -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Pet= er Sylvester Sent: Tuesday, August 21, 2012 4:35 AM To: pkix@ietf.org Subject: Re: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5= 280bis, Section 3.2) On 08/21/2012 01:01 AM, Martin Rex wrote: > David A. Cooper wrote: >> This just seems to be a long-winded way of saying that you don't have=20 >> a good example of a locally trusted OCSP responder because you don't=20 >> like the idea. > I'm not aware of any reasonable local OCSP responder scenario, any I=20 > have serious doubts that it exists at all. Prove me wrong. an application delegates all validation to a dedicated validation authority= which is managed by a security staff. a local ocsp responder implements co= mpany wide or personal trust policies and allows to manage them independent= ly from applications. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Tue Aug 21 07:30:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB4521F8686 for ; Tue, 21 Aug 2012 07:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.177 X-Spam-Level: X-Spam-Status: No, score=-10.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DlI-DebZ0oq for ; Tue, 21 Aug 2012 07:30:42 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7BECC21F86C3 for ; Tue, 21 Aug 2012 07:30:42 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7LEUYDS000734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Aug 2012 16:30:34 +0200 (MEST) In-Reply-To: <5033482C.4070602@edelweb.fr> To: Peter Sylvester Date: Tue, 21 Aug 2012 16:30:33 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120821143033.A7A421A1A2@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5280bis, Section 3.2) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 14:30:43 -0000 Peter Sylvester wrote: > On 08/21/2012 01:01 AM, Martin Rex wrote: > > David A. Cooper wrote: > >> This just seems to be a long-winded way of saying that you don't have a > >> good example of a locally trusted OCSP responder because you don't like > >> the idea. > > I'm not aware of any reasonable local OCSP responder scenario, any > > I have serious doubts that it exists at all. Prove me wrong. > > an application delegates all validation to a > dedicated validation authority which is managed > by a security staff. a local ocsp responder implements > company wide or personal trust policies and allows to > manage them independently from applications. I know that this theory exists. But using a self-signed local OCSP signer cert means that there is no such thing as revocation checking for an omnipotent irrevocable local OCSP signer. Rolling/updating that local OCSP signer key is completely out-of-scope for OCSP/rfc2560 and PKIX/rfc5280. The bottom line of such a (lack of) security archtecture is that revocation is merely a second thought, not something with a solid design. I would have at least expected the creation of an "local OCSP signer CA" that issues "local OCSP signer certs", so that the CA cert could be protected by a procedure that requires manual interaction and the rolling of the local OCSP signer cert would be based on regular PKIX mechanisms, rather than being completely out-of-scope. -Martin From david.cooper@nist.gov Tue Aug 21 07:44:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B152221F86A1 for ; Tue, 21 Aug 2012 07:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZSH1W2O4+yS for ; Tue, 21 Aug 2012 07:44:18 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id E36AF21F853E for ; Tue, 21 Aug 2012 07:44:17 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.379.0; Tue, 21 Aug 2012 10:44:12 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.379.0; Tue, 21 Aug 2012 10:44:09 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q7LEiCP4012053; Tue, 21 Aug 2012 10:44:13 -0400 Message-ID: <50339EBC.6050802@nist.gov> Date: Tue, 21 Aug 2012 10:44:12 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120723 Thunderbird/14.0 MIME-Version: 1.0 To: "mrex@sap.com" References: <20120821143033.A7A421A1A2@ld9781.wdf.sap.corp> In-Reply-To: <20120821143033.A7A421A1A2@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5280bis, Section 3.2) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 14:44:19 -0000 If you create a local CA for the purpose of issuing local OCSP signer certificates, how are you going to distribute that CA's public key? As a self-signed certificate? How are you going to revoke that CA's key if it becomes compromised? PKIs need trust anchors, and those trust anchors' keys have to be managed through out-of-band means, whether the key is used as a trust anchor for certification path validation or to verify OCSP responses. Are you trying to say that PKIX = RFC 5280? If that's the case, then why does http://datatracker.ietf.org/wg/pkix/ list so many other documents? Any suggestion that the use of a self-signed certificate that outside the scope of RFC 5280 cannot be within the scope of another document created by the PKIX WG is simply your personal opinion. And, as you would say, I violently disagree with that. On 08/21/2012 10:30 AM, Martin Rex wrote: > But using a self-signed local OCSP signer cert means that there > is no such thing as revocation checking for an omnipotent irrevocable > local OCSP signer. Rolling/updating that local OCSP signer key is > completely out-of-scope for OCSP/rfc2560 and PKIX/rfc5280. > > The bottom line of such a (lack of) security archtecture is that > revocation is merely a second thought, not something with a > solid design. > > I would have at least expected the creation of an "local OCSP signer CA" > that issues "local OCSP signer certs", so that the CA cert could be > protected by a procedure that requires manual interaction and the > rolling of the local OCSP signer cert would be based on regular > PKIX mechanisms, rather than being completely out-of-scope. > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From hallam@gmail.com Tue Aug 21 07:48:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBB821F84A7 for ; Tue, 21 Aug 2012 07:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.516 X-Spam-Level: X-Spam-Status: No, score=-5.516 tagged_above=-999 required=5 tests=[AWL=-1.917, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnfiA0Yz3ZEw for ; Tue, 21 Aug 2012 07:48:35 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF6E421F84E2 for ; Tue, 21 Aug 2012 07:48:35 -0700 (PDT) Received: by yhq56 with SMTP id 56so6478033yhq.31 for ; Tue, 21 Aug 2012 07:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TlAk13Kzqviy2hWzw3bcYVo70tLZK9IYsbO2bSGPaxE=; b=AWupxLsWJKpHFgSpnmN6dgwhYwtuEbbtAagvcvqc9VcFNlJpOjwuh0K+usNrDvsLbJ uKEESlkuqhYU3+CSt6x3pvG6Jeotbgf5H7MhRNS229sVuwVQ4qQw8bfGH6nFhIODYYKO PlrKzsn7n8P5QdKoa6sVbJPq/spQsc9GDwVGA9X468tzCB7U0gS8PlTTGN3x+PUWM2/o wWrQ2wnwba70XPh7x1bhF/mLrPI203h4liX7VkYGIK0N8Zz+s6tVyyUEROQmuhKtoL61 PSX9CmPdOAkJXEUwnvLRW0WK5wJqAF1BvdNWI0cfC0jzQyzTxKrCfjMKqT264xnorHn7 d8Qw== MIME-Version: 1.0 Received: by 10.60.18.168 with SMTP id x8mr13039649oed.18.1345560515330; Tue, 21 Aug 2012 07:48:35 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Tue, 21 Aug 2012 07:48:35 -0700 (PDT) Date: Tue, 21 Aug 2012 10:48:35 -0400 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [pkix] Fix to CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 14:48:36 -0000 I have already removed the language relating to public delegation points from the draft so that in the new scheme the CA MUST check for CAA records from the leaf node right up to the TLD. ie if there is no CAA record in example.com, then a CAA record in .com will apply. This change makes CAA consistent with the DNS architecture but makes the 'abusive CAA record' problem more severe, particularly if VeriSign was still a CA in addition to being the registry of .com. I propose to address this issue by changing the language of section 3 as follows: Current: Before issuing a certificate, a compliant CA MUST check for publication of a relevant CAA Resource Record(s). If such record(s) are published, the requested certificate MUST consistent with them if it is to be issued. If the certificate requested is not consistent with the relevant CAA RRs, the CA MUST NOT issue the certificate. New: Before issuing a certificate, a compliant CA MUST check for publication of an applicable CAA Resource Record set. If such a record set exists, a CA MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA Resource Record set or (2) that an exception specified in the applicable Certificate Policy or Certification Practices Statement Applies. Note that adoption of CAA is an option for the CA. So if they decide to implement, they can decide to implement with exceptions and that is OK, provided that the exceptions are documented and in the case of a public CA, that they are published. The practical effect of these changes is that they cancel each other out. The CA implementing CAA now has to climb the whole DNS tree each and every time regardless of what their policy says. They can however publish a policy that states 'we ignore CAA records in TLDs' or 'we ignore CAA records in domains listed in the CABForum Well Known issuing points list' or whatever. A CA could even point to a list on Wikipedia if they felt like, though I would think they would find it rather difficult to get Microsoft, Google, Mozilla and co to accept their CPS when they are trying to get their anchor embedded. In effect the policy loophole required because the world is complicated moves from the technical specification back into the policy world where it belongs. -- Website: http://hallambaker.com/ From peter.sylvester@edelweb.fr Tue Aug 21 08:00:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986CC21F86E4 for ; Tue, 21 Aug 2012 08:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEqy2iArQiAj for ; Tue, 21 Aug 2012 08:00:13 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id D25C121F869D for ; Tue, 21 Aug 2012 08:00:12 -0700 (PDT) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id E40CB5E09D; Tue, 21 Aug 2012 17:00:10 +0200 (CEST) Received: from mail1.on-x.com (mail1.on-x.com [192.168.10.66]) by mx1.on-x.com (Postfix) with ESMTP id D46595E095; Tue, 21 Aug 2012 17:00:10 +0200 (CEST) Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id 122CD5E280; Tue, 21 Aug 2012 17:00:12 +0200 (CEST) Received: from smtps.on-x.com (unknown [192.168.14.66]) by mail1.on-x.com (Postfix) with ESMTP id 019405E085; Tue, 21 Aug 2012 17:00:12 +0200 (CEST) Received: from [192.168.0.27] (unknown [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id 8A33E5E307; Tue, 21 Aug 2012 17:00:11 +0200 (CEST) Message-ID: <5033A27A.4060109@edelweb.fr> Date: Tue, 21 Aug 2012 17:00:10 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: mrex@sap.com References: <20120821143033.A7A421A1A2@ld9781.wdf.sap.corp> In-Reply-To: <20120821143033.A7A421A1A2@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Cc: pkix@ietf.org Subject: Re: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5280bis, Section 3.2) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:00:13 -0000 On 08/21/2012 04:30 PM, Martin Rex wrote: > I would have at least expected the creation of an "local OCSP signer CA" > that issues "local OCSP signer certs", Me 2 From denis.pinkas@bull.net Tue Aug 21 08:29:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64D121F877C for ; Tue, 21 Aug 2012 08:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtr52Wplm08H for ; Tue, 21 Aug 2012 08:29:55 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id C5BC021F8564 for ; Tue, 21 Aug 2012 08:29:46 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id DC04F181B6; Tue, 21 Aug 2012 17:29:45 +0200 (CEST) In-Reply-To: <20120820114552.803851A196@ld9781.wdf.sap.corp> References: <20120820114552.803851A196@ld9781.wdf.sap.corp> To: mrex@sap.com MIME-Version: 1.0 X-KeepSent: 9A9CF779:5288F3D7-C1257A60:006E6189; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Tue, 21 Aug 2012 17:29:44 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 21/08/2012 17:29:45, Serialize complete at 21/08/2012 17:29:45 Content-Type: multipart/alternative; boundary="=_alternative 00551AD7C1257A61_=" Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:29:57 -0000 Message en plusieurs parties au format MIME --=_alternative 00551AD7C1257A61_= Content-Type: text/plain; charset="US-ASCII" Martin, Responses are indicated with brackets [Denis: ...] > > If the OCSP requestor does not indicate that it supports new response > > semantics, then the OCSP responder can not distinguish rfc2560 clients > > from updated clients! > > The prerequisite for any negotiation of new features is that > > the request contains an indication about the clients additional > > capabilities. Without it, the server should not be _extremely_ > > conservative about changes in the response. > > [Denis: No. The solution does not need any change in the request] > Oh yes, you do. That requirement is described in rfc2560 section 4.4.3. > http://tools.ietf.org/html/rfc2560#section-4.4.3 > An OCSP server is not allowed to return something other than a > basic ocsp response unless the client has included a requestExtension > that indicates that the client recognizes other than id-pkix-ocsp-basic. [Denis: No. The proposal is fully compliant with id-pkix-ocsp-basic. It uses a field defined in id-pkix-ocsp-basic] > > > This solution uses a new singleResponse extension, which indicates that > > > the serial number of the certificate is not present > > > in the list of the certificates issued by the CA to which the OCSP > > > responder has access. > > > When this extension contains that indication, the critical flag SHALL be > > > set. > > Now that looks quite dangerous to me. A client that did not indicate > > to understand the extension is indistinguishable from an simple > > rfc2560 client. And the simple rfc2560 should drop the OCSP response > > with an unrecognized critical extension. Which will either result > > in the client to skip OCSP checking (bad) or to try other responders > > or CRLs (also bad). [Denis: No. You misread RFC 2560. A client which does not understand responseExtensions within ResponseData shall drop the whole response, but a client which does not understand singleExtensions with SingleResponse shall only drop the single response. I am proposing to use singleExtensions with SingleResponse]. > > [Denis: An OCSP client which does not recognize a critical extension > > within singleExtensions SHALL drop the individual response where that > > critical extension is present but may accept other responses within > > the field responses"] > I would not be surprised if a client that obtains a response for > an request about a singular cert would drop the entire response if > it contained an unexpected (=non-negotiated) critical responseExtension > in the first single response. [Denis: Thus, this would be a client that is not compliant. However, I recognize that RFC 2560 does not explain how to process singleExtensions with SingleResponse. In the draft I have prepared (and posted yesterday to the rfc editor), I am providing full details about: - the building of a request by an OCSP client, - the processing of a received request by an OCSP server, - the building of a response by an OCSP server, and - the processing of a response by an OCSP client]. > I would consider it strange if an OCSP response about a singular > cert contains multiple single repsonses about the exact same cert > with different properties (one with a critical extension, and one > without a critical extension). Since there is no specific ordering > defined for processing multiple single responses for one singular cert > in rfc2560, a response with multiple responses for a singular cert > would be a clear violation of the protocol defined rfc2560. [Denis: RFC 5280 states: A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. The extension I have drafted is compliant with this text (which was dedicated to PKCs). Depending upon its content, the extension will be marked critical or non critical by the server. A single OID is thus needed to define that extension. What is important is the way the client shall process it. I will re-use the text from RFC 5280 in the right order: 1) an extension that is recognized MUST be processed. 2) a critical extension that is not recognized must invalidate the SEQUENCE structure where it is present. 3) a non-critical extension that is not recognized may be ignored]. > > > OCSP clients unable to process this singleResponse extension SHALL > > > consider that the content of the single response > > > cannot be interpreted (this is the usual way to process an extension > > > that is marked critical) and this leads to an error > > > case (e.g. single response content invalid). > > This leads to the client/RP either skipping revocation or > > falling back to CRL checking--where the "not issued" state can > > not be conveyed at all. I consider this behaviour non-sensical > > with respect to the installed base. > > [Denis: Compliant clients shall not skip revocation as you say. > > However, your second argument is a valid consideration. I am preparing > > a draft for the definition of a new extension within singleExtensions > > and I have added the following note: > > NOTE: OCSP clients should not use a fallback mechanism based on CRLs > > when they encounter within singleExtensions an extension which > > is not understood and which is marked critical.] > You can not change behaviour of the installed base by adding a note > to a protocol update. The only thing you can reliably affect is > the behaviour of *NEW* implementations, and a hard-to-predict > subset of the installed base when it is patched. [Denis: A fallback mechanism cannot provide the same level of security as on line service. Anyway, The following question should be answered: - How many OCSP implementations are currently using a singleExtension which is marked critical ? - How many OCSP clients are currently using these OCSP implementations and are unable to understand these singleExtensions which is marked critical ? - How many of these OCSP clients are currently using a CRL fallback mechanism when they encounter a singleExtension which is marked critical ? I believe that the answer to the last question is none. So the point you raised is not an issue] > > The whitelist lookup should be performed with the certificate hash, > > and the validity enables an OCSP responder to determine whether the > > whitelist records it has access to are sufficiently "fresh" to > > determine whether the cert in question has been issued. > > [Denis: returning the hash provides the same benefit. The comparison > > will be done by the client rather than by the server]. > As someone regular doing customer support, I strongly dislike the reverse > approach. > This is an issue where it would be quite sensible to require the client > to send the certificate hash, so that the CA can detect when there is > a problem, and CA helpdesk has access to that information when the > cert hash mismatch leads to clients/RPs failing authentication--rather > than having to jump hoops in order to trace arbitrary third-party software > for reasons why it keeps failing cert revocation check> [Denis: Doing this, is opening the door to false detections. Let me explain: as a client I will send purposely wrong hashes. Using your wording "the CA can detect when there is a problem, and CA helpdesk has access to that information ...". I can keep busy the CA helpdesk nights and days, since most OCSP clients do not authenticate to the OCSP server]. > The client can use the best/strongest hash available, whereas the > server would have to use the weakest (when the client did not convey > anything through extensions about its capabilities. [Denis: the server shall use a hash algorithm that is as good (or as bad) as the one used by the client in its OCSP request. At least, the server is sure that the client will be able to use the same hash function, so interoperability is guaranteed]. > -Martin --=_alternative 00551AD7C1257A61_= Content-Type: text/html; charset="US-ASCII" Martin,

Responses are indicated with brackets [Denis: ...]
 
> > If the OCSP requestor does not indicate that it supports new response
> > semantics, then the OCSP responder can not distinguish rfc2560 clients
> > from updated clients!

> > The prerequisite for any negotiation of new features is that
> > the request contains an indication about the clients additional
> > capabilities.  Without it, the server should not be _extremely_
> > conservative about changes in the response.

> > [Denis: No. The solution does not need any change in the request]

> Oh yes, you do.  That requirement is described in rfc2560 section 4.4.3.

>   http://tools.ietf.org/html/rfc2560#section-4.4.3

> An OCSP server is not allowed to return something other than a
> basic ocsp response unless the client has included a requestExtension
> that indicates that the client recognizes other than id-pkix-ocsp-basic.
[Denis: No. The proposal is fully compliant with id-pkix-ocsp-basic.
It uses a field defined in id-pkix-ocsp-basic]

> > > This solution uses a new singleResponse extension, which indicates that
> > > the serial number of the certificate is not present
> > > in the list of the certificates issued by the CA to which the OCSP
> > > responder has access.

> > > When this extension contains that indication, the critical flag SHALL be
> > > set.

> > Now that looks quite dangerous to me.  A client that did not indicate
> > to understand the extension is indistinguishable from an simple
> > rfc2560 client.  And the simple rfc2560 should drop the OCSP response
> > with an unrecognized critical extension.  Which will either result
> > in the client to skip OCSP checking (bad) or to try other responders
> > or CRLs (also bad).
[Denis: No. You misread RFC 2560. A client which does not understand responseExtensions
within ResponseData shall drop the whole response, but a client which does not understand
singleExtensions with SingleResponse shall only drop the single response.
I am proposing to use singleExtensions with SingleResponse].
 
> > [Denis: An OCSP client which does not recognize a critical extension
> > within singleExtensions SHALL drop the individual response where that
> > critical extension is present but may accept other responses within
> > the field responses"]

> I would not be surprised if a client that obtains a response for
> an request about a singular cert would drop the entire response if
> it contained an unexpected (=non-negotiated) critical responseExtension
> in the first single response.
[Denis: Thus, this would be a client that is not compliant. However, I recognize that RFC 2560
does not explain how to process singleExtensions with SingleResponse. In the draft I have
prepared (and posted yesterday to the rfc editor), I am providing full details about:

    - the building of a request by an OCSP client,
     - the processing of a received request by an OCSP server,
     - the building of a response by an OCSP server, and
     - the processing of a response by an OCSP client].

> I would consider it strange if an OCSP response about a singular
> cert contains multiple single repsonses about the exact same cert
> with different properties (one with a critical extension, and one
> without a critical extension).  Since there is no specific ordering
> defined for processing multiple single responses for one singular cert
> in rfc2560, a response with multiple responses for a singular cert
> would be a clear violation of the protocol defined rfc2560.
[Denis: RFC 5280 states:

   A certificate-using system MUST reject the certificate if it encounters
   a critical extension it does not recognize or a critical extension
   that contains information that it cannot process.  A non-critical
   extension MAY be ignored if it is not recognized, but MUST be processed
   if it is recognized.

The extension I have drafted is compliant with this text (which was dedicated
to PKCs). Depending upon its content, the extension will be marked critical or
non critical by the server. A single OID is thus needed to define that extension.
What is important is the way the client shall process it. I will re-use the text
from RFC 5280 in the right order:

   1) an extension that is recognized MUST be processed.
   2) a critical extension that is not recognized must invalidate
      the SEQUENCE structure where it is present.
   3) a non-critical extension that is not recognized may be ignored].

> > > OCSP clients unable to process this singleResponse extension SHALL
> > > consider that the content of the single response
> > > cannot be interpreted (this is the usual way to process an extension
> > > that is marked critical) and this leads to an error
> > > case (e.g. single response content invalid).

> > This leads to the client/RP either skipping revocation or
> > falling back to CRL checking--where the "not issued" state can
> > not be conveyed at all.  I consider this behaviour non-sensical
> > with respect to the installed base.

> > [Denis: Compliant clients shall not skip revocation as you say.
> > However, your second argument is a valid consideration. I am preparing
> > a draft for the definition of a new extension within singleExtensions
> > and I have added the following note:

> >    NOTE: OCSP clients should not use a fallback mechanism based on CRLs
> >          when they encounter within singleExtensions an extension which
> >          is not understood and which is marked critical.]

> You can not change behaviour of the installed base by adding a note
> to a protocol update.  The only thing you can reliably affect is
> the behaviour of *NEW* implementations, and a hard-to-predict
> subset of the installed base when it is patched.
[Denis: A fallback mechanism cannot provide the same level of security as
on line service. Anyway, The following question should be answered:
 - How many OCSP implementations are currently using a singleExtension which is marked critical ?
 - How many OCSP clients are currently using these OCSP implementations and are unable to
  understand these singleExtensions which is marked critical ?
 - How many of these OCSP clients are currently using a CRL fallback mechanism when they encounter
   a singleExtension which is marked critical ?

I believe that the answer to the last question is none.
So the point you raised is not an issue]

> > The whitelist lookup should be performed with the certificate hash,
> > and the validity enables an OCSP responder to determine whether the
> > whitelist records it has access to are sufficiently "fresh" to
> > determine whether the cert in question has been issued.

> > [Denis: returning the hash provides the same benefit. The comparison
> > will be done by the client rather than by the server].

> As someone regular doing customer support, I strongly dislike the reverse
> approach.

> This is an issue where it would be quite sensible to require the client
> to send the certificate hash, so that the CA can detect when there is
> a problem, and CA helpdesk has access to that information when the
> cert hash mismatch leads to clients/RPs failing authentication--rather
> than having to jump hoops in order to trace arbitrary third-party software
> for reasons why it keeps failing cert revocation check>

[Denis: Doing this, is opening the door to false detections. Let me explain:
as a client I will send purposely wrong hashes. Using your wording "the CA can detect
when there is a problem, and CA helpdesk has access to that information ...".
I can keep busy the CA helpdesk nights and days, since most OCSP clients do not
authenticate to the OCSP server].

> The client can use the best/strongest hash available, whereas the
> server would have to use the weakest (when the client did not convey
> anything through extensions about its capabilities.
[Denis: the server shall use a hash algorithm that is as good (or as bad) as the one
used by the client in its OCSP request. At least, the server is sure that the client
will be able to use the same hash function, so interoperability is guaranteed].
 
> -Martin --=_alternative 00551AD7C1257A61_=-- From paul.hoffman@vpnc.org Tue Aug 21 09:02:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B5B21F87A7 for ; Tue, 21 Aug 2012 09:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOdSuHc7NVLv for ; Tue, 21 Aug 2012 09:02:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2FD21F879E for ; Tue, 21 Aug 2012 09:02:05 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7LG22P5061323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Aug 2012 09:02:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Paul Hoffman In-Reply-To: Date: Tue, 21 Aug 2012 09:02:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1485) Cc: pkix@ietf.org Subject: Re: [pkix] Fix to CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:02:06 -0000 On Aug 21, 2012, at 7:48 AM, Phillip Hallam-Baker = wrote: > I have already removed the language relating to public delegation > points from the draft so that in the new scheme the CA MUST check for > CAA records from the leaf node right up to the TLD. Just checking: this is in a draft we have not seen, correct? > ie if there is no CAA record in example.com, then a CAA record in .com > will apply. >=20 > This change makes CAA consistent with the DNS architecture but makes > the 'abusive CAA record' problem more severe, particularly if VeriSign > was still a CA in addition to being the registry of .com. No need to pick on your previous employer: there are other CAs with = "close ties" to other TLDs. > I propose to > address this issue by changing the language of section 3 as follows: >=20 > Current: >=20 > Before issuing a certificate, a compliant CA MUST check for = publication > of a relevant CAA Resource Record(s). If such record(s) are = published, > the requested certificate MUST consistent with them if it is > to be issued. > If the certificate requested is not consistent with the > relevant CAA RRs, > the CA MUST NOT issue the certificate. >=20 > New: >=20 > Before issuing a certificate, a compliant CA MUST check for = publication > of an applicable CAA Resource Record set. If such a record set > exists, a CA > MUST NOT issue a certificate unless the CA determines that = either > (1) the certificate request is consistent with the applicable > CAA Resource > Record set or (2) that an exception specified in the > applicable Certificate > Policy or Certification Practices Statement Applies. It doesn't look like you define "applicable"; I propose that you = continue to use "relevant". Your addition of the two options seems fine, = and appropriate for cases such as a CA whose CP or CPS says "we'll issue = certs even if we find a CAA record in the TLD". --Paul Hoffman= From ajs@anvilwalrusden.com Tue Aug 21 09:19:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4640521F8767 for ; Tue, 21 Aug 2012 09:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qulhijxcfOYe for ; Tue, 21 Aug 2012 09:19:46 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id D5C0E21F8760 for ; Tue, 21 Aug 2012 09:19:46 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D77288A031 for ; Tue, 21 Aug 2012 16:19:45 +0000 (UTC) Date: Tue, 21 Aug 2012 12:19:56 -0400 From: Andrew Sullivan To: pkix@ietf.org Message-ID: <20120821161956.GG33255@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] Fix to CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:19:47 -0000 On Tue, Aug 21, 2012 at 10:48:35AM -0400, Phillip Hallam-Baker wrote: > The practical effect of these changes is that they cancel each other > out. The CA implementing CAA now has to climb the whole DNS tree each > and every time regardless of what their policy says. They can however > publish a policy that states 'we ignore CAA records in TLDs' or 'we > ignore CAA records in domains listed in the CABForum Well Known > issuing points list' or whatever. Where "whatever" includes, "We ignore CAA records at any owner name except the owner name actually included in the request," or, "We ignore CAA records at any owner name except the owner name included in the request, or the direct parent," right? It would appear to do. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Tue Aug 21 09:25:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3815C21F86B1 for ; Tue, 21 Aug 2012 09:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wL-6TqjWd6e for ; Tue, 21 Aug 2012 09:25:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AA2C121F879D for ; Tue, 21 Aug 2012 09:25:49 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7LGPTMn068957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Aug 2012 09:25:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Paul Hoffman In-Reply-To: <20120821161956.GG33255@mx1.yitter.info> Date: Tue, 21 Aug 2012 09:25:30 -0700 Content-Transfer-Encoding: 7bit Message-Id: <1BCEBA03-06EA-45D1-BD22-A86139E6E280@vpnc.org> References: <20120821161956.GG33255@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1485) Cc: pkix@ietf.org Subject: Re: [pkix] Fix to CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:25:50 -0000 On Aug 21, 2012, at 9:19 AM, Andrew Sullivan wrote: > On Tue, Aug 21, 2012 at 10:48:35AM -0400, Phillip Hallam-Baker wrote: >> The practical effect of these changes is that they cancel each other >> out. The CA implementing CAA now has to climb the whole DNS tree each >> and every time regardless of what their policy says. They can however >> publish a policy that states 'we ignore CAA records in TLDs' or 'we >> ignore CAA records in domains listed in the CABForum Well Known >> issuing points list' or whatever. > > Where "whatever" includes, "We ignore CAA records at any owner name > except the owner name actually included in the request," or, "We > ignore CAA records at any owner name except the owner name included in > the request, or the direct parent," right? It would appear to do. Yes. Such is the nature of CPs and CPSs, the policy underpinnings of our PKI. --Paul Hoffman From mrex@sap.com Tue Aug 21 09:49:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4310A21F875A for ; Tue, 21 Aug 2012 09:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.178 X-Spam-Level: X-Spam-Status: No, score=-10.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq9peqEl-EcS for ; Tue, 21 Aug 2012 09:49:50 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 167A521F86D9 for ; Tue, 21 Aug 2012 09:49:49 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7LGnm55020202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Aug 2012 18:49:48 +0200 (MEST) In-Reply-To: To: denis.pinkas@bull.net Date: Tue, 21 Aug 2012 18:49:48 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120821164948.0A5D41A1A4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:49:51 -0000 denis.pinkas@bull.net wrote: > > [Denis: No. The proposal is fully compliant with id-pkix-ocsp-basic. > It uses a field defined in id-pkix-ocsp-basic] You're correct. I'm sorry, I misinterpreted the the ASN.1 structures in rfc2560. > > > > Now that looks quite dangerous to me. A client that did not indicate > > > to understand the extension is indistinguishable from an simple > > > rfc2560 client. And the simple rfc2560 should drop the OCSP response > > > with an unrecognized critical extension. Which will either result > > > in the client to skip OCSP checking (bad) or to try other responders > > > or CRLs (also bad). > > [Denis: No. You misread RFC 2560. A client which does not understand > responseExtensions within ResponseData shall drop the whole response, > but a client which does not understand singleExtensions with > SingleResponse shall only drop the single response. > I am proposing to use singleExtensions with SingleResponse]. That is actually not what rfc2560: Support for any specific extension is OPTIONAL. The critical flag SHOULD NOT be set for any of them. Section 4.4 suggests several useful extensions. Additional extensions MAY be defined in additional RFCs. Unrecognized extensions MUST be ignored (unless they have the critical flag set and are not understood). according to rfc2560, OCSP extensions that are critical may be ignored. The logical negation of MUST is "everything but MUST", which amounts to MAY, this is in particular encouraged by the "The critical flag SHOUD NOT be set for any of them.". > > > > [Denis: An OCSP client which does not recognize a critical extension > > > within singleExtensions SHALL drop the individual response where that > > > critical extension is present but may accept other responses within > > > the field responses"] > > > I would not be surprised if a client that obtains a response for > > an request about a singular cert would drop the entire response if > > it contained an unexpected (=non-negotiated) critical responseExtension > > in the first single response. > > [Denis: Thus, this would be a client that is not compliant. However, I > recognize that RFC 2560 does not explain how to process singleExtensions > with SingleResponse. In the draft I have prepared (and posted yesterday > to the rfc editor), I am providing full details about: > > - the building of a request by an OCSP client, > - the processing of a received request by an OCSP server, > - the building of a response by an OCSP server, and > - the processing of a response by an OCSP client]. The problem goes *much* deeper. rfc2560 does not define that there could be multiple singleResponses with different content contained in a reply, and the strategy how to evaluate them if there are. So is PERFECTLY compliant for an rfc2560 client to search the singleResponse for a match to the cert in question, look at the first match that is encountered, and not look at any other singleResponses AT ALL. Whether the rfc2560 processes the singleResponse sequence from top to bottom or from bottom to top, or in any other order, is UNDEFINED in rfc2560, which means, that there MUST only be one singleResponse for any particular cert, so that the result from processing the rfc2560 will be independent from the ordering in which the rfc2560 client/RP processes the singleResponse entries. > > > I would consider it strange if an OCSP response about a singular > > cert contains multiple single repsonses about the exact same cert > > with different properties (one with a critical extension, and one > > without a critical extension). Since there is no specific ordering > > defined for processing multiple single responses for one singular cert > > in rfc2560, a response with multiple responses for a singular cert > > would be a clear violation of the protocol defined rfc2560. > > [Denis: RFC 5280 states: > > A certificate-using system MUST reject the certificate if it encounters > a critical extension it does not recognize or a critical extension > that contains information that it cannot process. A non-critical > extension MAY be ignored if it is not recognized, but MUST be processed This text of rfc5280 applies exclusively to a certificate that contains critical certificate extensions. There is seperate text in rfc5280 that applies exclusively to critical CRL extensions any yet another seperate text in rfc5280 that applies exclusively to critical CRLEntryExtensions. None of the text in rfc5280 applies to rfc2560/OCSP extensions. > > 1) an extension that is recognized MUST be processed. > 2) a critical extension that is not recognized must invalidate > the SEQUENCE structure where it is present. > 3) a non-critical extension that is not recognized may be ignored]. But you must realize that this is a change of the OCSP protocol, and a requirement that does not apply to the installed base of rfc2560. What this would still be lacking is the definition of either a well-defined order of processing of singleResponses, or a well-defined behaviour for the presence of multiple (potentially conflicting) singleResponses for a single certificate. Sorting this out will also be something that does not apply to the installed base of rfc2560. At which point we're pretty much defining OCSP 2.0, even if it does not show on the version number of the wire protocol. An unsolicited, backwards-incompatible critical singleResponse extension in combination with two conflicting singleResponses for the exact same cert in a single OCSP response is a complete NO GO. It would have pretty much nothing in common with the original rfc2560 protocol. > > > You can not change behaviour of the installed base by adding a note > > to a protocol update. The only thing you can reliably affect is > > the behaviour of *NEW* implementations, and a hard-to-predict > > subset of the installed base when it is patched. > > [Denis: A fallback mechanism cannot provide the same level of security as > on line service. Anyway, The following question should be answered: > > - How many OCSP implementations are currently using a singleExtension > which is marked critical ? It is impossible to come up with any meaningful figures about the installed base of a 12-year old protocol. Doing backwards-incompatible in a NON-negotiating fashion (i.e. interoperability impairing) is incompatible with the spirit of the IETF and IETF protocols. > > > > [Denis: returning the hash provides the same benefit. The comparison > > > will be done by the client rather than by the server]. > > > As someone regular doing customer support, I strongly dislike the > > reverse approach. > > > This is an issue where it would be quite sensible to require the client > > to send the certificate hash, so that the CA can detect when there is > > a problem, and CA helpdesk has access to that information when the > > cert hash mismatch leads to clients/RPs failing authentication--rather > > than having to jump hoops in order to trace arbitrary third-party > > software for reasons why it keeps failing cert revocation check > > [Denis: Doing this, is opening the door to false detections. Let me > explain: > as a client I will send purposely wrong hashes. Using your wording > "the CA can detect when there is a problem, and CA helpdesk has access > to that information ...". > I can keep busy the CA helpdesk nights and days, > since most OCSP clients do not authenticate to the OCSP server]. Which part of "the CA helpdesk has access to that information" don't you understand? There will always be numerous ways to tick off "alarms" in IDSses/Monitoring and to keep Helpdesks busy, so there is no additional risk involved by being able to provide CA helpdesks with additional information to resolve customer support calls. > > > The client can use the best/strongest hash available, whereas the > > server would have to use the weakest (when the client did not convey > > anything through extensions about its capabilities. > > [Denis: the server shall use a hash algorithm that is as good (or as bad) > as the one used by the client in its OCSP request. At least, the server > is sure that the client will be able to use the same hash function, > so interoperability is guaranteed]. I actually prefer protocols that have a facility to negotiate to actively use that facility. the CertID in the request can only accomodate a single AlgorithmIdentifier, in which case the client would typically make a conservative assumption (SHA1), whereas the the additional singleRequestExtension could use SHA256 in addition, which means that the client will get some level of algorithm agility for free, without having to submit two independent requests. -Martin From hallam@gmail.com Tue Aug 21 09:50:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A29B21F87D6 for ; Tue, 21 Aug 2012 09:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.514 X-Spam-Level: X-Spam-Status: No, score=-5.514 tagged_above=-999 required=5 tests=[AWL=-1.915, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvg57HN0uin6 for ; Tue, 21 Aug 2012 09:50:20 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D392F21F875A for ; Tue, 21 Aug 2012 09:50:19 -0700 (PDT) Received: by yhq56 with SMTP id 56so14265yhq.31 for ; Tue, 21 Aug 2012 09:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MzCaXIsZb7Bps4qYlJK4NjGBhLCUYj9uShazKdwcMes=; b=u9hL/PoT2FY8l6/me98pmK2rEdoSN5Uc5GeDO7ZbiF0R056g3z3CBMYMFUcHZWYVkA bqsiwS83rt4uiTdT8386wAwv11w4htN2MONJBl5uCMqpvVNd0R7zhyDDTOWeAWCHRClY SoOobmc/tWHMEiuUoVsOkzR/VEQ56+qizcXu45wf87fh53sZiVAtuv6bhblja/SxBomW NsbgCyFC0vKUzBNl1Fpq+Kge7hsMyqajB7SxfLnjiHUVXkLYhF/So1Y2oD322c141vQq HYR6m1jMPeM8IfqkujzMB65K6LCddi3l01Imj/F5mez6AtKsS03j5oSMTk9wiFMbb92m YhmA== MIME-Version: 1.0 Received: by 10.60.172.236 with SMTP id bf12mr13367644oec.23.1345567819373; Tue, 21 Aug 2012 09:50:19 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Tue, 21 Aug 2012 09:50:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Aug 2012 12:50:19 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Fix to CAA X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:50:20 -0000 On Tue, Aug 21, 2012 at 12:02 PM, Paul Hoffman wrot= e: > On Aug 21, 2012, at 7:48 AM, Phillip Hallam-Baker wrot= e: > >> I have already removed the language relating to public delegation >> points from the draft so that in the new scheme the CA MUST check for >> CAA records from the leaf node right up to the TLD. > > Just checking: this is in a draft we have not seen, correct? Correct, I am working on it right now and bringing up sections for discussion so that hopefully -12 is the last one you need to read. >> I propose to >> address this issue by changing the language of section 3 as follows: >> >> Current: >> >> Before issuing a certificate, a compliant CA MUST check for publi= cation >> of a relevant CAA Resource Record(s). If such record(s) are publ= ished, >> the requested certificate MUST consistent with them if it is >> to be issued. >> If the certificate requested is not consistent with the >> relevant CAA RRs, >> the CA MUST NOT issue the certificate. >> >> New: >> >> Before issuing a certificate, a compliant CA MUST check for publi= cation >> of an applicable CAA Resource Record set. If such a record set >> exists, a CA >> MUST NOT issue a certificate unless the CA determines that either >> (1) the certificate request is consistent with the applicable >> CAA Resource >> Record set or (2) that an exception specified in the >> applicable Certificate >> Policy or Certification Practices Statement Applies. > > It doesn't look like you define "applicable"; I propose that you continue= to use "relevant". Your addition of the two options seems fine, and approp= riate for cases such as a CA whose CP or CPS says "we'll issue certs even i= f we find a CAA record in the TLD". OK, relevant. --=20 Website: http://hallambaker.com/ From mrex@sap.com Tue Aug 21 10:02:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB5A21F869D for ; Tue, 21 Aug 2012 10:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbStPVX6vgAz for ; Tue, 21 Aug 2012 10:02:13 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7046D21F86A1 for ; Tue, 21 Aug 2012 10:02:13 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7LH2BU4025178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Aug 2012 19:02:11 +0200 (MEST) In-Reply-To: <50339EBC.6050802@nist.gov> To: "David A. Cooper" Date: Tue, 21 Aug 2012 19:02:10 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120821170210.D49611A1A4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" Subject: Re: [pkix] Locally Trusted OCSP Responders (was Re: new text for 5280bis, Section 3.2) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 17:02:14 -0000 David A. Cooper wrote: > > If you create a local CA for the purpose of issuing local OCSP signer > certificates, how are you going to distribute that CA's public key? As > a self-signed certificate? How are you going to revoke that CA's key if > it becomes compromised? PKIs need trust anchors, and those trust > anchors' keys have to be managed through out-of-band means, whether the > key is used as a trust anchor for certification path validation or to > verify OCSP responses. I'm sure there are plenty of resources available that describe the advantage of _not_ distributing CA certs of online CAs as trust anchors, but instead create a seperate offline rootCA instance where it is less of a problem that its cert is not subject to regular revocation checking. > > Are you trying to say that PKIX = RFC 5280? If that's the case, then > why does http://datatracker.ietf.org/wg/pkix/ list so many other > documents? Any suggestion that the use of a self-signed certificate > that outside the scope of RFC 5280 cannot be within the scope of another > document created by the PKIX WG is simply your personal opinion. And, > as you would say, I violently disagree with that. By using a local OCSP signer CA to issue local OCSP signer certs (possibly short-lived, so that revocation checking for that cert can be entirely obviated), all involved certs (local OCSP signer CA and local OCSP signer cert) can be fully PKIX-compliant certs and PKIX compliant path validation can be performed, rather than doing out-of-scope certs with out-of-scope key management. While rfc5280 does not define trust anchor management itself, it can not exist without trust anchors. The idea here is to make new scenarios work exactly like existing scenarios, so that existing protocols and procedures can be re-used. Adding certificate revocation checking to a PKI by creating an omnipotent irrevocable self-signed OCSP signer entity, looks extremely odd to me, I'm sorry. -Martin From hallam@gmail.com Tue Aug 21 13:04:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA5621F8763 for ; Tue, 21 Aug 2012 13:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[AWL=-1.902, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvef0B9+m5+A for ; Tue, 21 Aug 2012 13:04:04 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7031C21F875C for ; Tue, 21 Aug 2012 13:04:04 -0700 (PDT) Received: by ghbg16 with SMTP id g16so205598ghb.31 for ; Tue, 21 Aug 2012 13:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O98jMu0woqU5DBt4mHviI5E9W3uktZrPb/Cob3RLKys=; b=pHVISMGSPrFzOXgfKxNH1TGtxuap85s4Gnm1BBpzHdQvoVTw3d8TDX/a9PpztBkDGr KNd+BuhZJlQ4vgLOq4w9mlmJccbX0oX7fRKTAmma3QcRfi+b4iMd7uz60w21vfljfYKh ddSoFBzQ7rAy92AJ8TH3lQviAerHWkEm7wVH/hvoI8AdkFCpbC+KFoCFm+RF6g72CpbT UT8lWSN1i2pViNdM8yHgVa4edIuZauv61DF1jvWtApDLcvZACdF019WnK6d7tbLAuJNJ pvIOMTrDFYW8U1PjcAUzPqFN4Debr539+kuSpdgr77gCVpXOFrMtqF6g9B2Isfw+5/te DgOg== MIME-Version: 1.0 Received: by 10.60.29.72 with SMTP id i8mr13671832oeh.26.1345579443953; Tue, 21 Aug 2012 13:04:03 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Tue, 21 Aug 2012 13:04:03 -0700 (PDT) In-Reply-To: <20120820185222.50D5A1A198@ld9781.wdf.sap.corp> References: <20120820185222.50D5A1A198@ld9781.wdf.sap.corp> Date: Tue, 21 Aug 2012 16:04:03 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 20:04:05 -0000 On Mon, Aug 20, 2012 at 2:52 PM, Martin Rex wrote: > Phillip Hallam-Baker wrote: >> >> I don't think what we actually do here matters at all provided that >> (1) we all interpret the same signals to mean the same thing and (2) >> we can actually distinguish between the status situations that require >> it. >> >> The fact that OCSP does not distinguish 'good' from 'utterly bad' has >> turned out to be a very bad thing in practice. > > The originial protocol failed to recognized (from the discussion of > "good" in rfc2560 section 2.2) that there is a need for bad status > codes besides revoked. But by lacking to define other states from the > start, the only reasonable way forward is to use "revoked" to convey > all variations of known "bad", and to sort out the details through extensions. +1 > It seems silly to have an OCSP responder label a known "bad" certificate > "good" or likewise to chicken out with an "unknown" reply, which will cause > RPs to ignore the result or fallback to CRL checking (and the latter > will result in a "good" classification of "bad" states that a CRL can > not represent). +1 If unknown with a marked critical extension has the desired effect, I would be ok with it. But I agree it is not a nice solution. I don't see what is bad about defining the ASN1 'revoked' status to mean 'not valid' and adding in an extension to allow the server to report additional status info > A "fallback to other OCSP server" would be even more silly, because > if the other OCSP server would return "good" or "bad", then the first > OCSP server should have provided this answer in the first place. > And if the other OCSP server also provides "unknown", then it is > an obvious waste of resources, ultimately ending in the RP attempting > CRL-checking (with a result of "good"), or skipping revocation checking > entirely. Agreed, we have to stop the OCSP chasing chain there. The object is to have the responder give a report that as a minimum causes the cert to be rejected and preferably causes a loud complaint somewhere. > Adding situations where OCSP-based revocation will fail to provide an > answer (i.e. "unknown" rather than "good" or "bad/revoked") will make > hard fail clients/RP further unlikely. What is proposed is not an 'unknown' response so much as redefining the semantics of unknown for the case of an authoritative server. >> An authoritative response should hopefully have some common connection >> to the trust anchor for the cert, > > Ouch. The "common trust anchor" is a security vulerability in the > definition of authorized CRL signers! rfc2560 originally does not > have this vulnerability, and I strongly opposed to drilling the CRL > security hole into the OCSP spec. What happened in practice is pretty ugly. See all the questions about what extensions the cert should have.... >> Well how did it decide to send the query there in the first place? If >> the responder was found by following a URL in the cert then it is >> authoritative. Otherwise the responder must have been configured out > > Strong disagree. It is *completely* irrelevant how the OCSP response was > actually obtained (from cache, stapled in a TLS extension, out-of-band, > proxied by a local OCSP responder, etc.). Good point, I had forgotten about stapling. -- Website: http://hallambaker.com/ From denis.pinkas@bull.net Wed Aug 22 05:07:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B5A21F86A0 for ; Wed, 22 Aug 2012 05:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntsurd6Yqq-Y for ; Wed, 22 Aug 2012 05:07:21 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1DC21F8634 for ; Wed, 22 Aug 2012 05:07:19 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id C23931813B; Wed, 22 Aug 2012 14:07:18 +0200 (CEST) In-Reply-To: <20120821164948.0A5D41A1A4@ld9781.wdf.sap.corp> References: <20120821164948.0A5D41A1A4@ld9781.wdf.sap.corp> To: mrex@sap.com MIME-Version: 1.0 X-KeepSent: 45EEA8D6:9706EED8-C1257A62:00346A3A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 22 Aug 2012 14:07:17 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 22/08/2012 14:07:18, Serialize complete at 22/08/2012 14:07:18 Content-Type: multipart/alternative; boundary="=_alternative 00370A0DC1257A62_=" Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 12:07:22 -0000 Message en plusieurs parties au format MIME --=_alternative 00370A0DC1257A62_= Content-Type: text/plain; charset="US-ASCII" > > > > Now that looks quite dangerous to me. A client that did not indicate > > > > to understand the extension is indistinguishable from an simple > > > > rfc2560 client. And the simple rfc2560 should drop the OCSP response > > > > with an unrecognized critical extension. Which will either result > > > > in the client to skip OCSP checking (bad) or to try other responders > > > > or CRLs (also bad). > > > > [Denis: No. You misread RFC 2560. A client which does not understand > > responseExtensions within ResponseData shall drop the whole response, > > but a client which does not understand singleExtensions with > > SingleResponse shall only drop the single response. > > I am proposing to use singleExtensions with SingleResponse]. > > That is actually not what rfc2560: > > Support for any specific extension is OPTIONAL. The critical flag > SHOULD NOT be set for any of them. Section 4.4 suggests several > useful extensions. Additional extensions MAY be defined in > additional RFCs. Unrecognized extensions MUST be ignored (unless they > have the critical flag set and are not understood). > > according to rfc2560, OCSP extensions that are critical may be ignored. > The logical negation of MUST is "everything but MUST", which amounts to MAY, > this is in particular encouraged by the "The critical flag SHOUD NOT be > set for any of them.". [Denis: ... but the text states "Unrecognized extensions MUST be ignored (unless they have the critical flag set and are not understood). > > > > [Denis: An OCSP client which does not recognize a critical extension > > > > within singleExtensions SHALL drop the individual response where that > > > > critical extension is present but may accept other responses within > > > > the field responses"] > > > > > I would not be surprised if a client that obtains a response for > > > an request about a singular cert would drop the entire response if > > > it contained an unexpected (=non-negotiated) critical responseExtension > > > in the first single response. > > > > [Denis: Thus, this would be a client that is not compliant. However, I > > recognize that RFC 2560 does not explain how to process singleExtensions > > with SingleResponse. In the draft I have prepared (and posted yesterday > > to the rfc editor), I am providing full details about: > > > > - the building of a request by an OCSP client, > > - the processing of a received request by an OCSP server, > > - the building of a response by an OCSP server, and > > - the processing of a response by an OCSP client]. > > The problem goes *much* deeper. rfc2560 does not define that there could > be multiple singleResponses with different content contained in a reply, > and the strategy how to evaluate them if there are. [Denis: this is not fully correct. RFC 2560 does define that there may be multiple singleResponses in a reply. However it is true that there is no algorithm for their individual evaluation]. > So is PERFECTLY compliant for an rfc2560 client to search the singleResponse > for a match to the cert in question, look at the first match that is > encountered, and not look at any other singleResponses AT ALL. > > Whether the rfc2560 processes the singleResponse sequence from top to > bottom or from bottom to top, or in any other order, is UNDEFINED in > rfc2560, which means, that there MUST only be one singleResponse for > any particular cert, so that the result from processing the rfc2560 > will be independent from the ordering in which the rfc2560 client/RP > processes the singleResponse entries. [Denis: this is not an issue since a singleExtension only applies to a single response] > > > I would consider it strange if an OCSP response about a singular > > > cert contains multiple single repsonses about the exact same cert > > > with different properties (one with a critical extension, and one > > > without a critical extension). Since there is no specific ordering > > > defined for processing multiple single responses for one singular cert > > > in rfc2560, a response with multiple responses for a singular cert > > > would be a clear violation of the protocol defined rfc2560. > > > > [Denis: RFC 5280 states: > > > > A certificate-using system MUST reject the certificate if it encounters > > a critical extension it does not recognize or a critical extension > > that contains information that it cannot process. A non-critical > > extension MAY be ignored if it is not recognized, but MUST be processed > > This text of rfc5280 applies exclusively to a certificate that contains > critical certificate extensions. There is seperate text in rfc5280 that > applies exclusively to critical CRL extensions any yet another seperate > text in rfc5280 that applies exclusively to critical CRLEntryExtensions. > > None of the text in rfc5280 applies to rfc2560/OCSP extensions. > > > > 1) an extension that is recognized MUST be processed. > > 2) a critical extension that is not recognized must invalidate > > the SEQUENCE structure where it is present. > > 3) a non-critical extension that is not recognized may be ignored]. > > But you must realize that this is a change of the OCSP protocol, and > a requirement that does not apply to the installed base of rfc2560. [Denis: ...RFC 2560 states: "Unrecognized extensions MUST be ignored (unless they have the critical flag set and are not understood). The single change would be to remove the sentence : "The critical flag SHOULD NOT be set for any of them". > What this would still be lacking is the definition of either > a well-defined order of processing of singleResponses, or a well-defined > behaviour for the presence of multiple (potentially conflicting) > singleResponses for a single certificate. Sorting this out will > also be something that does not apply to the installed base of rfc2560. [Denis: I am only thinking of a single extension. So there is not yet any conflict possible. If the PKIX WG defines critical extensions that may conflict, then the rule will be indicated at that time]. > At which point we're pretty much defining OCSP 2.0, even if it does not > show on the version number of the wire protocol. [Denis: No. I don't think so] > An unsolicited, backwards-incompatible critical singleResponse extension > in combination with two conflicting singleResponses for the exact same > cert in a single OCSP response is a complete NO GO. It would have > pretty much nothing in common with the original rfc2560 protocol. > > > You can not change behaviour of the installed base by adding a note > > > to a protocol update. The only thing you can reliably affect is > > > the behaviour of *NEW* implementations, and a hard-to-predict > > > subset of the installed base when it is patched. > > > > [Denis: A fallback mechanism cannot provide the same level of security as > > on line service. Anyway, The following question should be answered: > > > > - How many OCSP implementations are currently using a singleExtension > > which is marked critical ? > > It is impossible to come up with any meaningful figures about the > installed base of a 12-year old protocol. Doing backwards-incompatible > in a NON-negotiating fashion (i.e. interoperability impairing) is > incompatible with the spirit of the IETF and IETF protocols. > > > > > [Denis: returning the hash provides the same benefit. The comparison > > > > will be done by the client rather than by the server]. > > > > > As someone regular doing customer support, I strongly dislike the > > > reverse approach. > > > > > This is an issue where it would be quite sensible to require the client > > > to send the certificate hash, so that the CA can detect when there is > > > a problem, and CA helpdesk has access to that information when the > > > cert hash mismatch leads to clients/RPs failing authentication--rather > > > than having to jump hoops in order to trace arbitrary third-party > > > software for reasons why it keeps failing cert revocation check > > > > [Denis: Doing this, is opening the door to false detections. Let me > > explain: > > as a client I will send purposely wrong hashes. Using your wording > > "the CA can detect when there is a problem, and CA helpdesk has access > > to that information ...". > > I can keep busy the CA helpdesk nights and days, > > since most OCSP clients do not authenticate to the OCSP server]. > > Which part of "the CA helpdesk has access to that information" don't > you understand? There will always be numerous ways to tick off "alarms" > in IDSses/Monitoring and to keep Helpdesks busy, so there is no > additional risk involved by being able to provide CA helpdesks with > additional information to resolve customer support calls. [Denis: You missed the point. The helpdesk will be triggered by the CA (rather than customer support calls) for problems which do not exist. > > > The client can use the best/strongest hash available, whereas the > > > server would have to use the weakest (when the client did not convey > > > anything through extensions about its capabilities. > > > > [Denis: the server shall use a hash algorithm that is as good (or as bad) > > as the one used by the client in its OCSP request. At least, the server > > is sure that the client will be able to use the same hash function, > > so interoperability is guaranteed]. > I actually prefer protocols that have a facility to negotiate to actively > use that facility. the CertID in the request can only accomodate a > single AlgorithmIdentifier, in which case the client would typically > make a conservative assumption (SHA1), whereas the the additional > singleRequestExtension could use SHA256 in addition, which means that > the client will get some level of algorithm agility for free, without > having to submit two independent requests. [Denis: It looks like applying the following sentence: Why make it simple when we can make it complex ? :-) I believe it is better to have a solution which avoids the use any kind of singleRequestExtension] > -Martin --=_alternative 00370A0DC1257A62_= Content-Type: text/html; charset="US-ASCII" > > > > Now that looks quite dangerous to me.  A client that did not indicate
> > > > to understand the extension is indistinguishable from an simple
> > > > rfc2560 client.  And the simple rfc2560 should drop the OCSP response
> > > > with an unrecognized critical extension.  Which will either result
> > > > in the client to skip OCSP checking (bad) or to try other responders
> > > > or CRLs (also bad).
> >
> > [Denis: No. You misread RFC 2560. A client which does not understand
> > responseExtensions within ResponseData shall drop the whole response,
> > but a client which does not understand singleExtensions with
> > SingleResponse shall only drop the single response.
> > I am proposing to use singleExtensions with SingleResponse].
>
> That is actually not what rfc2560:
>
>    Support for any specific extension is OPTIONAL. The critical flag
>    SHOULD NOT be set for any of them.  Section 4.4 suggests several
>    useful extensions.  Additional extensions MAY be defined in
>    additional RFCs. Unrecognized extensions MUST be ignored (unless they
>    have the critical flag set and are not understood).
>
> according to rfc2560, OCSP extensions that are critical may be ignored.
> The logical negation of MUST is "everything but MUST", which amounts to MAY,
> this is in particular encouraged by the "The critical flag SHOUD NOT be
> set for any of them.".
[Denis: ... but the text states "Unrecognized extensions MUST be ignored
          (unless they have the critical flag set and are not understood).


> > > > [Denis: An OCSP client which does not recognize a critical extension
> > > > within singleExtensions SHALL drop the individual response where that
> > > > critical extension is present but may accept other responses within
> > > > the field responses"]
> >  
> > > I would not be surprised if a client that obtains a response for
> > > an request about a singular cert would drop the entire response if
> > > it contained an unexpected (=non-negotiated) critical responseExtension
> > > in the first single response.
> >
> > [Denis: Thus, this would be a client that is not compliant. However, I
> > recognize that RFC 2560 does not explain how to process singleExtensions
> > with SingleResponse. In the draft I have prepared (and posted yesterday
> > to the rfc editor), I am providing full details about:
> >
> >      - the building of a request by an OCSP client,
> >      - the processing of a received request by an OCSP server,
> >      - the building of a response by an OCSP server, and
> >      - the processing of a response by an OCSP client].
>
> The problem goes *much* deeper.  rfc2560 does not define that there could
> be multiple singleResponses with different content contained in a reply,
> and the strategy how to evaluate them if there are.
[Denis: this is not fully correct. RFC 2560 does define that there may be
multiple singleResponses in a reply. However it is true that there is no
algorithm for their individual evaluation].

 
> So is PERFECTLY compliant for an rfc2560 client to search the singleResponse
> for a match to the cert in question, look at the first match that is
> encountered, and not look at any other singleResponses AT ALL.
>
> Whether the rfc2560 processes the singleResponse sequence from top to
> bottom or from bottom to top, or in any other order, is UNDEFINED in
> rfc2560, which means, that there MUST only be one singleResponse for
> any particular cert, so that the result from processing the rfc2560
> will be independent from the ordering in which the rfc2560 client/RP
> processes the singleResponse entries.
[Denis: this is not an issue since a singleExtension only applies to a
single response]
 
> > > I would consider it strange if an OCSP response about a singular
> > > cert contains multiple single repsonses about the exact same cert
> > > with different properties (one with a critical extension, and one
> > > without a critical extension).  Since there is no specific ordering
> > > defined for processing multiple single responses for one singular cert
> > > in rfc2560, a response with multiple responses for a singular cert
> > > would be a clear violation of the protocol defined rfc2560.
> >
> > [Denis: RFC 5280 states:
> >
> >    A certificate-using system MUST reject the certificate if it encounters
> >    a critical extension it does not recognize or a critical extension
> >    that contains information that it cannot process.  A non-critical
> >    extension MAY be ignored if it is not recognized, but MUST be processed
>
> This text of rfc5280 applies exclusively to a certificate that contains
> critical certificate extensions.  There is seperate text in rfc5280 that
> applies exclusively to critical CRL extensions any yet another seperate
> text in rfc5280 that applies exclusively to critical CRLEntryExtensions.
>
> None of the text in rfc5280 applies to rfc2560/OCSP extensions.
> >
> >    1) an extension that is recognized MUST be processed.
> >    2) a critical extension that is not recognized must invalidate
> >       the SEQUENCE structure where it is present.
> >    3) a non-critical extension that is not recognized may be ignored].
>
> But you must realize that this is a change of the OCSP protocol, and
> a requirement that does not apply to the installed base of rfc2560.
[Denis: ...RFC 2560 states: "Unrecognized extensions MUST be ignored
          (unless they have the critical flag set and are not understood).
           The single change would be to remove the sentence :
          "The critical flag SHOULD NOT be set for any of them".

> What this would still be lacking is the definition of either
> a well-defined order of processing of singleResponses, or a well-defined
> behaviour for the presence of multiple (potentially conflicting)
> singleResponses for a single certificate.  Sorting this out will
> also be something that does not apply to the installed base of rfc2560.
[Denis: I am only thinking of a single extension. So there is not yet any conflict possible.
If the PKIX WG defines critical extensions that may conflict, then the rule will be indicated
at that time].
 

> At which point we're pretty much defining OCSP 2.0, even if it does not
> show on the version number of the wire protocol.
[Denis:  No. I don't think so]

> An unsolicited, backwards-incompatible critical singleResponse extension
> in combination with two conflicting singleResponses for the exact same
> cert in a single OCSP response is a complete NO GO.  It would have
> pretty much nothing in common with the original rfc2560 protocol.

> > > You can not change behaviour of the installed base by adding a note
> > > to a protocol update.  The only thing you can reliably affect is
> > > the behaviour of *NEW* implementations, and a hard-to-predict
> > > subset of the installed base when it is patched.
> >
> > [Denis: A fallback mechanism cannot provide the same level of security as
> > on line service. Anyway, The following question should be answered:
> >
> >  - How many OCSP implementations are currently using a singleExtension
> >    which is marked critical ?
>
> It is impossible to come up with any meaningful figures about the
> installed base of a 12-year old protocol.  Doing backwards-incompatible
> in a NON-negotiating fashion (i.e. interoperability impairing) is
> incompatible with the spirit of the IETF and IETF protocols.
>
> > > > [Denis: returning the hash provides the same benefit. The comparison
> > > > will be done by the client rather than by the server].
> >  
> > > As someone regular doing customer support, I strongly dislike the
> > > reverse approach.
> >  
> > > This is an issue where it would be quite sensible to require the client
> > > to send the certificate hash, so that the CA can detect when there is
> > > a problem, and CA helpdesk has access to that information when the
> > > cert hash mismatch leads to clients/RPs failing authentication--rather
> > > than having to jump hoops in order to trace arbitrary third-party
> > > software for reasons why it keeps failing cert revocation check
> >
> > [Denis: Doing this, is opening the door to false detections. Let me
> > explain:
> > as a client I will send purposely wrong hashes. Using your wording
> > "the CA can detect when there is a problem, and CA helpdesk has access
> > to that information ...".
> > I can keep busy the CA helpdesk nights and days,
> > since most OCSP clients do not authenticate to the OCSP server].
>
> Which part of "the CA helpdesk has access to that information" don't
> you understand?  There will always be numerous ways to tick off "alarms"
> in IDSses/Monitoring and to keep Helpdesks busy, so there is no
> additional risk involved by being able to provide CA helpdesks with
> additional information to resolve customer support calls.
[Denis: You missed the point. The helpdesk will be triggered by the CA
(rather than customer support calls) for problems which do not exist.

> > > The client can use the best/strongest hash available, whereas the
> > > server would have to use the weakest (when the client did not convey
> > > anything through extensions about its capabilities.
> >
> > [Denis: the server shall use a hash algorithm that is as good (or as bad)
> > as the one used by the client in its OCSP request. At least, the server
> > is sure that the client will be able to use the same hash function,
> > so interoperability is guaranteed].

> I actually prefer protocols that have a facility to negotiate to actively
> use that facility.  the CertID in the request can only accomodate a
> single AlgorithmIdentifier, in which case the client would typically
> make a conservative assumption (SHA1), whereas the the additional
> singleRequestExtension could use SHA256 in addition, which means that
> the client will get some level of algorithm agility for free, without
> having to submit two independent requests.
[Denis: It looks like applying the following sentence:
Why make it simple when we can make it complex ? :-)
I believe it is better to have a solution which avoids
the use any kind of singleRequestExtension]

> -Martin
 --=_alternative 00370A0DC1257A62_=-- From denis.pinkas@bull.net Wed Aug 22 07:00:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8E721F83EF for ; Wed, 22 Aug 2012 07:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vCK1sRbxcwV for ; Wed, 22 Aug 2012 07:00:10 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id D8DAD21F8535 for ; Wed, 22 Aug 2012 07:00:09 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 4103A1812C; Wed, 22 Aug 2012 16:00:08 +0200 (CEST) In-Reply-To: References: <20120821164948.0A5D41A1A4@ld9781.wdf.sap.corp> To: Martin Rex MIME-Version: 1.0 X-KeepSent: 59CE4EF5:079A2B24-C1257A62:004C541F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 22 Aug 2012 16:00:07 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 22/08/2012 16:00:07, Serialize complete at 22/08/2012 16:00:07 Content-Type: multipart/alternative; boundary="=_alternative 004CE1B4C1257A62_=" Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 14:00:14 -0000 Message en plusieurs parties au format MIME --=_alternative 004CE1B4C1257A62_= Content-Type: text/plain; charset="US-ASCII" Martin, I answered too quickly to your last email. The text you mentioned ("The critical flag SHOULD NOT be set for any of them") is in section 4.1.2, i.e. Notes on the Request Syntax. So it only applies to the request, not to the response. There is no text in RFC 2560 which forbids (or even does not recommend) to use critical single extensions within a response. Denis ======================================================================== > > > > > Now that looks quite dangerous to me. A client that did not indicate > > > > > to understand the extension is indistinguishable from an simple > > > > > rfc2560 client. And the simple rfc2560 should drop the OCSP response > > > > > with an unrecognized critical extension. Which will either result > > > > > in the client to skip OCSP checking (bad) or to try other responders > > > > > or CRLs (also bad). > > > > > > [Denis: No. You misread RFC 2560. A client which does not understand > > > responseExtensions within ResponseData shall drop the whole response, > > > but a client which does not understand singleExtensions with > > > SingleResponse shall only drop the single response. > > > I am proposing to use singleExtensions with SingleResponse]. > > > > That is actually not what rfc2560: > > > > Support for any specific extension is OPTIONAL. The critical flag > > SHOULD NOT be set for any of them. Section 4.4 suggests several > > useful extensions. Additional extensions MAY be defined in > > additional RFCs. Unrecognized extensions MUST be ignored (unless they > > have the critical flag set and are not understood). > > > > according to rfc2560, OCSP extensions that are critical may be ignored. > > The logical negation of MUST is "everything but MUST", which amounts to MAY, > > this is in particular encouraged by the "The critical flag SHOUD NOT be > > set for any of them.". > > [Denis: ... but the text states "Unrecognized extensions MUST be ignored > (unless they have the critical flag set and are not understood). > > > > > > > [Denis: An OCSP client which does not recognize a critical extension > > > > > within singleExtensions SHALL drop the individual response where that > > > > > critical extension is present but may accept other responses within > > > > > the field responses"] > > > > > > > I would not be surprised if a client that obtains a response for > > > > an request about a singular cert would drop the entire response if > > > > it contained an unexpected (=non-negotiated) critical responseExtension > > > > in the first single response. > > > > > > [Denis: Thus, this would be a client that is not compliant. However, I > > > recognize that RFC 2560 does not explain how to process singleExtensions > > > with SingleResponse. In the draft I have prepared (and posted yesterday > > > to the rfc editor), I am providing full details about: > > > > > > - the building of a request by an OCSP client, > > > - the processing of a received request by an OCSP server, > > > - the building of a response by an OCSP server, and > > > - the processing of a response by an OCSP client]. > > > > The problem goes *much* deeper. rfc2560 does not define that there could > > be multiple singleResponses with different content contained in a reply, > > and the strategy how to evaluate them if there are. > > [Denis: this is not fully correct. RFC 2560 does define that there may be > multiple singleResponses in a reply. However it is true that there is no > algorithm for their individual evaluation]. > > > > So is PERFECTLY compliant for an rfc2560 client to search the singleResponse > > for a match to the cert in question, look at the first match that is > > encountered, and not look at any other singleResponses AT ALL. > > > > Whether the rfc2560 processes the singleResponse sequence from top to > > bottom or from bottom to top, or in any other order, is UNDEFINED in > > rfc2560, which means, that there MUST only be one singleResponse for > > any particular cert, so that the result from processing the rfc2560 > > will be independent from the ordering in which the rfc2560 client/RP > > processes the singleResponse entries. > > [Denis: this is not an issue since a singleExtension only applies to a > single response] > > > > > I would consider it strange if an OCSP response about a singular > > > > cert contains multiple single repsonses about the exact same cert > > > > with different properties (one with a critical extension, and one > > > > without a critical extension). Since there is no specific ordering > > > > defined for processing multiple single responses for one singular cert > > > > in rfc2560, a response with multiple responses for a singular cert > > > > would be a clear violation of the protocol defined rfc2560. > > > > > > [Denis: RFC 5280 states: > > > > > > A certificate-using system MUST reject the certificate if it encounters > > > a critical extension it does not recognize or a critical extension > > > that contains information that it cannot process. A non-critical > > > extension MAY be ignored if it is not recognized, but MUST beprocessed > > > > This text of rfc5280 applies exclusively to a certificate that contains > > critical certificate extensions. There is seperate text in rfc5280 that > > applies exclusively to critical CRL extensions any yet another seperate > > text in rfc5280 that applies exclusively to critical CRLEntryExtensions. > > > > None of the text in rfc5280 applies to rfc2560/OCSP extensions. > > > > > > 1) an extension that is recognized MUST be processed. > > > 2) a critical extension that is not recognized must invalidate > > > the SEQUENCE structure where it is present. > > > 3) a non-critical extension that is not recognized may be ignored]. > > > > But you must realize that this is a change of the OCSP protocol, and > > a requirement that does not apply to the installed base of rfc2560. > > [Denis: ...RFC 2560 states: "Unrecognized extensions MUST be ignored > (unless they have the critical flag set and are not understood). > The single change would be to remove the sentence : > "The critical flag SHOULD NOT be set for any of them". > > > What this would still be lacking is the definition of either > > a well-defined order of processing of singleResponses, or a well-defined > > behaviour for the presence of multiple (potentially conflicting) > > singleResponses for a single certificate. Sorting this out will > > also be something that does not apply to the installed base of rfc2560. > > [Denis: I am only thinking of a single extension. So there is not > yet any conflict possible. > If the PKIX WG defines critical extensions that may conflict, then > the rule will be indicated > at that time]. > > > > At which point we're pretty much defining OCSP 2.0, even if it does not > > show on the version number of the wire protocol. > > [Denis: No. I don't think so] > > > An unsolicited, backwards-incompatible critical singleResponse extension > > in combination with two conflicting singleResponses for the exact same > > cert in a single OCSP response is a complete NO GO. It would have > > pretty much nothing in common with the original rfc2560 protocol. > > > > > You can not change behaviour of the installed base by adding a note > > > > to a protocol update. The only thing you can reliably affect is > > > > the behaviour of *NEW* implementations, and a hard-to-predict > > > > subset of the installed base when it is patched. > > > > > > [Denis: A fallback mechanism cannot provide the same level of security as > > > on line service. Anyway, The following question should be answered: > > > > > > - How many OCSP implementations are currently using a singleExtension > > > which is marked critical ? > > > > It is impossible to come up with any meaningful figures about the > > installed base of a 12-year old protocol. Doing backwards-incompatible > > in a NON-negotiating fashion (i.e. interoperability impairing) is > > incompatible with the spirit of the IETF and IETF protocols. > > > > > > > [Denis: returning the hash provides the same benefit. The comparison > > > > > will be done by the client rather than by the server]. > > > > > > > As someone regular doing customer support, I strongly dislike the > > > > reverse approach. > > > > > > > This is an issue where it would be quite sensible to require the client > > > > to send the certificate hash, so that the CA can detect when there is > > > > a problem, and CA helpdesk has access to that information when the > > > > cert hash mismatch leads to clients/RPs failing authentication--rather > > > > than having to jump hoops in order to trace arbitrary third-party > > > > software for reasons why it keeps failing cert revocation check > > > > > > [Denis: Doing this, is opening the door to false detections. Let me > > > explain: > > > as a client I will send purposely wrong hashes. Using your wording > > > "the CA can detect when there is a problem, and CA helpdesk has access > > > to that information ...". > > > I can keep busy the CA helpdesk nights and days, > > > since most OCSP clients do not authenticate to the OCSP server]. > > > > Which part of "the CA helpdesk has access to that information" don't > > you understand? There will always be numerous ways to tick off "alarms" > > in IDSses/Monitoring and to keep Helpdesks busy, so there is no > > additional risk involved by being able to provide CA helpdesks with > > additional information to resolve customer support calls. > > [Denis: You missed the point. The helpdesk will be triggered by the CA > (rather than customer support calls) for problems which do not exist. > > > > > The client can use the best/strongest hash available, whereas the > > > > server would have to use the weakest (when the client did not convey > > > > anything through extensions about its capabilities. > > > > > > [Denis: the server shall use a hash algorithm that is as good (or as bad) > > > as the one used by the client in its OCSP request. At least, the server > > > is sure that the client will be able to use the same hash function, > > > so interoperability is guaranteed]. > > > I actually prefer protocols that have a facility to negotiate to actively > > use that facility. the CertID in the request can only accomodate a > > single AlgorithmIdentifier, in which case the client would typically > > make a conservative assumption (SHA1), whereas the the additional > > singleRequestExtension could use SHA256 in addition, which means that > > the client will get some level of algorithm agility for free, without > > having to submit two independent requests. > > [Denis: It looks like applying the following sentence: > Why make it simple when we can make it complex ? :-) > I believe it is better to have a solution which avoids > the use any kind of singleRequestExtension] > > > -Martin_______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=_alternative 004CE1B4C1257A62_= Content-Type: text/html; charset="US-ASCII" Martin,

I answered too quickly to your last email.

The text you mentioned ("The critical flag SHOULD NOT be set for any of them")
is in section 4.1.2, i.e. Notes on the Request Syntax.

So it only applies to the request, not to the response.

There is no text in RFC 2560 which forbids (or even does not recommend) to use critical single extensions
within a response.

Denis

========================================================================



> > > > > Now that looks quite dangerous to me.  A client that did not indicate
> > > > > to understand the extension is indistinguishable from an simple
> > > > > rfc2560 client.  And the simple rfc2560 should drop the OCSP response
> > > > > with an unrecognized critical extension.  Which will either result
> > > > > in the client to skip OCSP checking (bad) or to try other responders
> > > > > or CRLs (also bad).
> > >
> > > [Denis: No. You misread RFC 2560. A client which does not understand
> > > responseExtensions within ResponseData shall drop the whole response,
> > > but a client which does not understand singleExtensions with
> > > SingleResponse shall only drop the single response.
> > > I am proposing to use singleExtensions with SingleResponse].
> >
> > That is actually not what rfc2560:
> >
> >    Support for any specific extension is OPTIONAL. The critical flag
> >    SHOULD NOT be set for any of them.  Section 4.4 suggests several
> >    useful extensions.  Additional extensions MAY be defined in
> >    additional RFCs. Unrecognized extensions MUST be ignored (unless they
> >    have the critical flag set and are not understood).
> >
> > according to rfc2560, OCSP extensions that are critical may be ignored.
> > The logical negation of MUST is "everything but MUST", which amounts to MAY,
> > this is in particular encouraged by the "The critical flag SHOUD NOT be
> > set for any of them.".
>
> [Denis: ... but the text states "Unrecognized extensions MUST be ignored
>           (unless they have the critical flag set and are not understood).
>
>
> > > > > [Denis: An OCSP client which does not recognize a critical extension
> > > > > within singleExtensions SHALL drop the individual response where that
> > > > > critical extension is present but may accept other responses within
> > > > > the field responses"]
> > >  
> > > > I would not be surprised if a client that obtains a response for
> > > > an request about a singular cert would drop the entire response if
> > > > it contained an unexpected (=non-negotiated) critical responseExtension
> > > > in the first single response.
> > >
> > > [Denis: Thus, this would be a client that is not compliant. However, I
> > > recognize that RFC 2560 does not explain how to process singleExtensions
> > > with SingleResponse. In the draft I have prepared (and posted yesterday
> > > to the rfc editor), I am providing full details about:
> > >
> > >      - the building of a request by an OCSP client,
> > >      - the processing of a received request by an OCSP server,
> > >      - the building of a response by an OCSP server, and
> > >      - the processing of a response by an OCSP client].
> >
> > The problem goes *much* deeper.  rfc2560 does not define that there could
> > be multiple singleResponses with different content contained in a reply,
> > and the strategy how to evaluate them if there are.
>
> [Denis: this is not fully correct. RFC 2560 does define that there may be
> multiple singleResponses in a reply. However it is true that there is no
> algorithm for their individual evaluation].
>
>  
> > So is PERFECTLY compliant for an rfc2560 client to search the singleResponse
> > for a match to the cert in question, look at the first match that is
> > encountered, and not look at any other singleResponses AT ALL.
> >
> > Whether the rfc2560 processes the singleResponse sequence from top to
> > bottom or from bottom to top, or in any other order, is UNDEFINED in
> > rfc2560, which means, that there MUST only be one singleResponse for
> > any particular cert, so that the result from processing the rfc2560
> > will be independent from the ordering in which the rfc2560 client/RP
> > processes the singleResponse entries.
>
> [Denis: this is not an issue since a singleExtension only applies to a
> single response]
>  
> > > > I would consider it strange if an OCSP response about a singular
> > > > cert contains multiple single repsonses about the exact same cert
> > > > with different properties (one with a critical extension, and one
> > > > without a critical extension).  Since there is no specific ordering
> > > > defined for processing multiple single responses for one singular cert
> > > > in rfc2560, a response with multiple responses for a singular cert
> > > > would be a clear violation of the protocol defined rfc2560.
> > >
> > > [Denis: RFC 5280 states:
> > >
> > >    A certificate-using system MUST reject the certificate if it encounters
> > >    a critical extension it does not recognize or a critical extension
> > >    that contains information that it cannot process.  A non-critical
> > >    extension MAY be ignored if it is not recognized, but MUST beprocessed
> >
> > This text of rfc5280 applies exclusively to a certificate that contains
> > critical certificate extensions.  There is seperate text in rfc5280 that
> > applies exclusively to critical CRL extensions any yet another seperate
> > text in rfc5280 that applies exclusively to critical CRLEntryExtensions.
> >
> > None of the text in rfc5280 applies to rfc2560/OCSP extensions.
> > >
> > >    1) an extension that is recognized MUST be processed.
> > >    2) a critical extension that is not recognized must invalidate
> > >       the SEQUENCE structure where it is present.
> > >    3) a non-critical extension that is not recognized may be ignored].
> >
> > But you must realize that this is a change of the OCSP protocol, and
> > a requirement that does not apply to the installed base of rfc2560.
>
> [Denis: ...RFC 2560 states: "Unrecognized extensions MUST be ignored
>           (unless they have the critical flag set and are not understood).
>            The single change would be to remove the sentence :
>           "The critical flag SHOULD NOT be set for any of them".
>
> > What this would still be lacking is the definition of either
> > a well-defined order of processing of singleResponses, or a well-defined
> > behaviour for the presence of multiple (potentially conflicting)
> > singleResponses for a single certificate.  Sorting this out will
> > also be something that does not apply to the installed base of rfc2560.
>
> [Denis: I am only thinking of a single extension. So there is not
> yet any conflict possible.
> If the PKIX WG defines critical extensions that may conflict, then
> the rule will be indicated
> at that time].
>  
>
> > At which point we're pretty much defining OCSP 2.0, even if it does not
> > show on the version number of the wire protocol.
>
> [Denis:  No. I don't think so]
>
> > An unsolicited, backwards-incompatible critical singleResponse extension
> > in combination with two conflicting singleResponses for the exact same
> > cert in a single OCSP response is a complete NO GO.  It would have
> > pretty much nothing in common with the original rfc2560 protocol.
>
> > > > You can not change behaviour of the installed base by adding a note
> > > > to a protocol update.  The only thing you can reliably affect is
> > > > the behaviour of *NEW* implementations, and a hard-to-predict
> > > > subset of the installed base when it is patched.
> > >
> > > [Denis: A fallback mechanism cannot provide the same level of security as
> > > on line service. Anyway, The following question should be answered:
> > >
> > >  - How many OCSP implementations are currently using a singleExtension
> > >    which is marked critical ?
> >
> > It is impossible to come up with any meaningful figures about the
> > installed base of a 12-year old protocol.  Doing backwards-incompatible
> > in a NON-negotiating fashion (i.e. interoperability impairing) is
> > incompatible with the spirit of the IETF and IETF protocols.
> >
> > > > > [Denis: returning the hash provides the same benefit. The comparison
> > > > > will be done by the client rather than by the server].
> > >  
> > > > As someone regular doing customer support, I strongly dislike the
> > > > reverse approach.
> > >  
> > > > This is an issue where it would be quite sensible to require the client
> > > > to send the certificate hash, so that the CA can detect when there is
> > > > a problem, and CA helpdesk has access to that information when the
> > > > cert hash mismatch leads to clients/RPs failing authentication--rather
> > > > than having to jump hoops in order to trace arbitrary third-party
> > > > software for reasons why it keeps failing cert revocation check
> > >
> > > [Denis: Doing this, is opening the door to false detections. Let me
> > > explain:
> > > as a client I will send purposely wrong hashes. Using your wording
> > > "the CA can detect when there is a problem, and CA helpdesk has access
> > > to that information ...".
> > > I can keep busy the CA helpdesk nights and days,
> > > since most OCSP clients do not authenticate to the OCSP server].
> >
> > Which part of "the CA helpdesk has access to that information" don't
> > you understand?  There will always be numerous ways to tick off "alarms"
> > in IDSses/Monitoring and to keep Helpdesks busy, so there is no
> > additional risk involved by being able to provide CA helpdesks with
> > additional information to resolve customer support calls.
>
> [Denis: You missed the point. The helpdesk will be triggered by the CA
> (rather than customer support calls) for problems which do not exist.
>
> > > > The client can use the best/strongest hash available, whereas the
> > > > server would have to use the weakest (when the client did not convey
> > > > anything through extensions about its capabilities.
> > >
> > > [Denis: the server shall use a hash algorithm that is as good (or as bad)
> > > as the one used by the client in its OCSP request. At least, the server
> > > is sure that the client will be able to use the same hash function,
> > > so interoperability is guaranteed].
>
> > I actually prefer protocols that have a facility to negotiate to actively
> > use that facility.  the CertID in the request can only accomodate a
> > single AlgorithmIdentifier, in which case the client would typically
> > make a conservative assumption (SHA1), whereas the the additional
> > singleRequestExtension could use SHA256 in addition, which means that
> > the client will get some level of algorithm agility for free, without
> > having to submit two independent requests.
>
> [Denis: It looks like applying the following sentence:
> Why make it simple when we can make it complex ? :-)
> I believe it is better to have a solution which avoids
> the use any kind of singleRequestExtension]
>
> > -Martin_______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
 --=_alternative 004CE1B4C1257A62_=-- From mrex@sap.com Wed Aug 22 07:42:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10BB21F8464 for ; Wed, 22 Aug 2012 07:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.156 X-Spam-Level: X-Spam-Status: No, score=-10.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCDLWWdKYwBS for ; Wed, 22 Aug 2012 07:42:35 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4296221F8569 for ; Wed, 22 Aug 2012 07:42:34 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7MEgW3G001292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Aug 2012 16:42:32 +0200 (MEST) In-Reply-To: To: denis.pinkas@bull.net Date: Wed, 22 Aug 2012 16:42:31 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120822144231.CA38C1A1A7@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 14:42:39 -0000 denis.pinkas@bull.net wrote: > > I answered too quickly to your last email. > > The text you mentioned > ("The critical flag SHOULD NOT be set for any of them") > is in section 4.1.2, i.e. Notes on the Request Syntax. > > So it only applies to the request, not to the response. > > There is no text in RFC 2560 which forbids (or even does not recommend) > to use critical single extensions within a response. It could be that I still do not understand what you're really trying to accomplish and how. I do not have a problem with critical extensions (in both request and response) in principle, I just wanted to point out that the presence of (and dealing with) a an extension that is marked critical is not specified in rfc2560, which means that ANY behaviour is conforming, although there is some likelyhood that the presence of an unrecognized extension that is marked critical will result in the complete response to be dropped/ignored. Therefore sending a critical extension in an OCSP request would probably be a bad idea, because a server that does not recognize it may return an error (and it would require a second request or out-of-band meta-knowledge to know whether a server supports the extension). The OCSP server returning an OCSP resonse with a critical singleResponse extension, which has *NOT* been offered in the OCSP request through a non-critical singleRequest extensions is a BAD idea. Nothing in rfc2560 descibed the exact semantics of critical singleResponseExtensions, so for rfc2560 they're simply prohibited--that is an implicit consistency requirement. That an unrecognized critical singleResponse extension applies should not cause the rejection of the whole response is not backed by any existing specifications. rfc2560 certainly does not specify it. So the behaviour is undefined. For those who believe that rfc5280 should provide fallback guidance, look at what semantics rfc5280 specifies for critical crlEntryExtensions: http://tools.ietf.org/html/rfc5280#section-5.3 If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL to determine the status of any certificates. However, applications may ignore unrecognized non-critical CRL entry extensions. rfc5280 specifies that a single unrecognized critical crlEntryExtension anywhere in the CRL should cause the RP to completely ignore/drop the entire signed object (the complete CRL). The semantics that you are asking--the criticality of a singleResponseExtensions applies only to that particular singleResponse and should be ignored with respect to all other information in the signed object (the OCSP response) is not specified in rfc2560, and is the exact opposite of the sematics specified in a vaguely similar situation in section 5.3 of PKIX/rfc5280 for the criticality of CRLEntryExtensions. I'm OK with extending OCSP to support such semantics, provided that these semantics are properly negotiated(!) between OCSP requestor and OCSP responder, which means that the OCSP request MUST contain a request extension indicating support for these semantics. However, since there are scenarios where OCSP responses are forwarded _without_ an original OCSP request from the client that is supposed to process them (e.g. in the TLS extensions for OCSP response stapling), use of critical OCSP response extensions ought to be limited to very exceptional situations that will not occur in regular usage scenarios where e.g. OCSP response stapling is desirable. -Martin From iesg-secretary@ietf.org Wed Aug 22 08:05:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1053C21F8508; Wed, 22 Aug 2012 08:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYUUCPUZ9Ni4; Wed, 22 Aug 2012 08:05:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FC321F850D; Wed, 22 Aug 2012 08:05:43 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120822150543.16802.27813.idtracker@ietfa.amsl.com> Date: Wed, 22 Aug 2012 08:05:43 -0700 Cc: pkix@ietf.org Subject: [pkix] Last Call: (Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) to Proposed Standard X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 15:05:48 -0000 The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-09-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications/ballot/ No IPR declarations have been submitted directly on this I-D. From denis.pinkas@bull.net Wed Aug 22 09:57:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1371A21F85B1 for ; Wed, 22 Aug 2012 09:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCv3lm-XLnqP for ; Wed, 22 Aug 2012 09:57:11 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id CDE0721F84C8 for ; Wed, 22 Aug 2012 09:57:10 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id CC3AE1804A; Wed, 22 Aug 2012 18:57:09 +0200 (CEST) In-Reply-To: <20120822144231.CA38C1A1A7@ld9781.wdf.sap.corp> References: <20120822144231.CA38C1A1A7@ld9781.wdf.sap.corp> To: mrex@sap.com MIME-Version: 1.0 X-KeepSent: C324333D:F618EFD0-C1257A62:00592839; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 22 Aug 2012 18:57:09 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 22/08/2012 18:57:09, Serialize complete at 22/08/2012 18:57:09 Content-Type: multipart/alternative; boundary="=_alternative 005D0482C1257A62_=" Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 16:57:12 -0000 Message en plusieurs parties au format MIME --=_alternative 005D0482C1257A62_= Content-Type: text/plain; charset="US-ASCII" Martin, > > I answered too quickly to your last email. > > > > The text you mentioned > > ("The critical flag SHOULD NOT be set for any of them") > > is in section 4.1.2, i.e. Notes on the Request Syntax. > > > > So it only applies to the request, not to the response. > > > > There is no text in RFC 2560 which forbids (or even does not recommend) > > to use critical single extensions within a response. > > It could be that I still do not understand what you're really > trying to accomplish and how. > > I do not have a problem with critical extensions (in both request and > response) in principle, I just wanted to point out that the presence > of (and dealing with) a an extension that is marked critical is > not specified in rfc2560, which means that ANY behaviour is conforming, > although there is some likelyhood that the presence of an unrecognized > extension that is marked critical will result in the complete response > to be dropped/ignored. A singleExtensions that is critical and not recognized will result in the single response to be dropped/ignored. > Therefore sending a critical extension in an OCSP request would probably > be a bad idea, because a server that does not recognize it may return > an error (and it would require a second request or out-of-band meta-knowledge > to know whether a server supports the extension). I am not discussing such a case. > The OCSP server returning an OCSP resonse with a critical singleResponse > extension, which has *NOT* been offered in the OCSP request through > a non-critical singleRequest extensions is a BAD idea. Nothing > in rfc2560 descibed the exact semantics of critical singleResponseExtensions, > so for rfc2560 they're simply prohibited--that is an implicit consistency > requirement. This is one of the many topics on which RFC 2560 is obscure; hence why we are working on 2560bis. > That an unrecognized critical singleResponse extension applies should > not cause the rejection of the whole response is not backed by any > existing specifications. rfc2560 certainly does not specify it. > So the behaviour is undefined. This is one of the many topics on which RFC 2560 is obscure; hence why we are working on 2560bis. > For those who believe that rfc5280 should provide fallback guidance, > look at what semantics rfc5280 specifies for critical crlEntryExtensions: > > http://tools.ietf.org/html/rfc5280#section-5.3 > > If a CRL > contains a critical CRL entry extension that the application cannot > process, then the application MUST NOT use that CRL to determine the > status of any certificates. However, applications may ignore > unrecognized non-critical CRL entry extensions. > rfc5280 specifies that a single unrecognized critical crlEntryExtension > anywhere in the CRL should cause the RP to completely ignore/drop the > entire signed object (the complete CRL). This is an interesting point which deserves a separate thread. I believe this is an error and that we should discuss it as an errata to RFC 5280. > The semantics that you are asking--the criticality of a > singleResponseExtensions applies only to that particular singleResponse > and should be ignored with respect to all other information in the > signed object (the OCSP response) is not specified in rfc2560, > and is the exact opposite of the sematics specified in a vaguely > similar situation in section 5.3 of PKIX/rfc5280 for the criticality of > CRLEntryExtensions. > I'm OK with extending OCSP to support such semantics, provided that > these semantics are properly negotiated(!) between OCSP requestor and OCSP > responder, which means that the OCSP request MUST contain a request > extension indicating support for these semantics. I now understand your point, but I do not think that the reject of a whole response is logical if there is a critical unrecognized extension within a single response. > However, since there are scenarios where OCSP responses are forwarded > _without_ an original OCSP request from the client that is supposed > to process them (e.g. in the TLS extensions for OCSP response stapling), > use of critical OCSP response extensions ought to be limited to > very exceptional situations that will not occur in regular usage > scenarios where e.g. OCSP response stapling is desirable. > -Martin --=_alternative 005D0482C1257A62_= Content-Type: text/html; charset="US-ASCII" Martin,

> > I answered too quickly to your last email.
> >
> > The text you mentioned
> > ("The critical flag SHOULD NOT be set for any of them")
> > is in section 4.1.2, i.e. Notes on the Request Syntax.
> >
> > So it only applies to the request, not to the response.
> >
> > There is no text in RFC 2560 which forbids (or even does not recommend)
> > to use critical single extensions within a response.
>
> It could be that I still do not understand what you're really
> trying to accomplish and how.
>
> I do not have a problem with critical extensions (in both request and
> response) in principle,  I just wanted to point out that the presence
> of (and dealing with) a an extension that is marked critical is
> not specified in rfc2560, which means that ANY behaviour is conforming,
> although there is some likelyhood that the presence of an unrecognized
> extension that is marked critical will result in the complete response
> to be dropped/ignored.

A singleExtensions that is critical and not recognized will result in the single response to be dropped/ignored.

> Therefore sending a critical extension in an OCSP request would probably
> be a bad idea, because a server that does not recognize it may return
> an error (and it would require a second request or out-of-band meta-knowledge
> to know whether a server supports the extension).
I am not discussing such a case.

> The OCSP server returning an OCSP resonse with a critical singleResponse
> extension, which has *NOT* been offered in the OCSP request through
> a non-critical singleRequest extensions is a BAD idea.  Nothing
> in rfc2560 descibed the exact semantics of critical singleResponseExtensions,
> so for rfc2560 they're simply prohibited--that is an implicit consistency
> requirement.

This is one of the many topics on which RFC 2560 is obscure; hence why we are working on 2560bis.

> That an unrecognized critical singleResponse extension applies should
> not cause the rejection of the whole response is not backed by any
> existing specifications.  rfc2560 certainly does not specify it.
> So the behaviour is undefined.
This is one of the many topics on which RFC 2560 is obscure; hence why we are working on 2560bis.
 
> For those who believe that rfc5280 should provide fallback guidance,
> look at what semantics rfc5280 specifies for critical crlEntryExtensions:
>
>   http://tools.ietf.org/html/rfc5280#section-5.3
>
>                                                          If a CRL
>    contains a critical CRL entry extension that the application cannot
>    process, then the application MUST NOT use that CRL to determine the
>    status of any certificates.  However, applications may ignore
>    unrecognized non-critical CRL entry extensions.

> rfc5280 specifies that a single unrecognized critical crlEntryExtension
> anywhere in the CRL should cause the RP to completely ignore/drop the
> entire signed object (the complete CRL).
This is an interesting point which deserves a separate thread.
I believe this is an error and that we should discuss it as an errata to RFC 5280.

> The semantics that you are asking--the criticality of a
> singleResponseExtensions applies only to that particular singleResponse
> and should be ignored with respect to all other information in the
> signed object (the OCSP response) is not specified in rfc2560,
> and is the exact opposite of the sematics specified in a vaguely
> similar situation in section 5.3 of PKIX/rfc5280 for the criticality of
> CRLEntryExtensions.

> I'm OK with extending OCSP to support such semantics, provided that
> these semantics are properly negotiated(!) between OCSP requestor and OCSP
> responder, which means that the OCSP request MUST contain a request
> extension indicating support for these semantics.
I now understand your point, but I do not think that the reject of a whole response is logical
if there is a critical unrecognized extension within a single response.

> However, since there are scenarios where OCSP responses are forwarded
> _without_ an original OCSP request from the client that is supposed
> to process them (e.g. in the TLS extensions for OCSP response stapling),
> use of critical OCSP response extensions ought to be limited to
> very exceptional situations that will not occur in regular usage
> scenarios where e.g. OCSP response stapling is desirable.

> -Martin
 --=_alternative 005D0482C1257A62_=-- From denis.pinkas@bull.net Wed Aug 22 09:59:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A4A21F8610 for ; Wed, 22 Aug 2012 09:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-larIoDQ5bh for ; Wed, 22 Aug 2012 09:59:13 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 11FE821F8644 for ; Wed, 22 Aug 2012 09:59:13 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id CF74A18041 for ; Wed, 22 Aug 2012 18:59:11 +0200 (CEST) To: pkix@ietf.org MIME-Version: 1.0 X-KeepSent: CA1B2349:15BDB7F8-C1257A62:005BE395; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 22 Aug 2012 18:59:11 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 22/08/2012 18:59:11, Serialize complete at 22/08/2012 18:59:11 Content-Type: multipart/alternative; boundary="=_alternative 005D2D00C1257A62_=" Subject: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 16:59:13 -0000 Message en plusieurs parties au format MIME --=_alternative 005D2D00C1257A62_= Content-Type: text/plain; charset="US-ASCII" RFC 5280 states on page 69, section 5.3 : CRL Entry Extensions "If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL to determine the status of any certificates". This should be changed into: "If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL entry to determine the status of this certificate". Denis --=_alternative 005D2D00C1257A62_= Content-Type: text/html; charset="US-ASCII" RFC 5280 states on page 69, section 5.3 : CRL Entry Extensions

"If a CRL contains a critical CRL entry extension that the application cannot
process, then the application MUST NOT use that CRL to determine the status
of any certificates".

This should be changed into:

"If a CRL contains a critical CRL entry extension that the application cannot
process, then the application MUST NOT use that CRL entry to determine the status
of this certificate".

Denis --=_alternative 005D2D00C1257A62_=-- From Scott@DigiCert.com Wed Aug 22 10:35:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D3221F858A for ; Wed, 22 Aug 2012 10:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgO9CASotANg for ; Wed, 22 Aug 2012 10:35:06 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA8921F8578 for ; Wed, 22 Aug 2012 10:35:06 -0700 (PDT) Received: from [10.211.55.9] (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id D58091AE061; Wed, 22 Aug 2012 11:35:05 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1345656905; bh=XPhOrRdDiuzeCuU0Pl6DlLoBfGpIETPlalWwwR3EIVo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HAWOmYz8yCZpn7rqCQua7dGMPP/poM+6nJMtJdeGVrJqwiUd0aicdjS1XYI89Vjmc QtOB035Wgp+0/tbmqNRvOxOohVIxkw9U7btDWqJvym65yaYDkWf+1VApVBctZyhbGi KkIt5SFwUkak7Ilq/bKxlLLLwg7s55k6242QRoNs= Message-ID: <50351840.2030104@DigiCert.com> Date: Wed, 22 Aug 2012 11:34:56 -0600 From: Scott Rea User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] OCSP over DNS X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 17:35:08 -0000 Sorry for the long delay answering you here Stefan, I was traveling... In my mind, we want to enable both these since they are aimed at two different stakeholder groups - one option is a decision for site owners (stapling) and the other is a decision for CAs (OCSP-over-DNS), even though they may both be considered to be aimed at performance improvement for certificate validation checking. In terms of RRTYPE, that is still under discussion and specifically deployment is the main consideration here. There are certainly pros and cons to defining a new type or not, and it may be a question we settle by taking it to the list. For now, perhaps I can encourage Max or Olafur to regurgitate a summary of our internal discussions to replay for the list some of our thinking to date. Regards, _Scott On 8/14/2012 11:34 PM, Stefan Santesson wrote: > Scott, > > How is this proposal positioned in relation to OCSP stapling. > Would we need either or, or both? > > I've seen two questions on what RRTYPE you would use, whether a new need > to be defined and what deployment issues that would bring to the table. > What is your position on that? > > /Stefan > > > On 12-08-02 9:47 AM, "Scott Rea" wrote: > >> G'day Folks, >> >> yesterday at PKIX we had some folks supporting the proposed OCSP over >> DNS protocol (see: >> https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/) and some >> folks who said they did not like the idea. Time was short and I failed >> to get further feedback from the folks who "hated" (yes that was the >> exact phrase that was used) the idea as to WHY they do not support the >> idea. >> Would those folks be willing to post their objections/justifications to >> the list, and if are not quite ready to make a public declaration, >> please send Max or I an email directly off-list as to reasons why you >> would not support this proposal? >> >> Scott Rea or >> Massimiliano Pala >> >> Regards, >> >> -- >> Scott Rea >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > -- Scott Rea From paul.hoffman@vpnc.org Wed Aug 22 11:06:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E57421F8625 for ; Wed, 22 Aug 2012 11:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYd2i4MMe4ix for ; Wed, 22 Aug 2012 11:06:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C0EC621F8648 for ; Wed, 22 Aug 2012 11:06:19 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7MI6HTB028900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 22 Aug 2012 11:06:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Paul Hoffman In-Reply-To: Date: Wed, 22 Aug 2012 11:06:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "pkix@ietf.org PKIX" X-Mailer: Apple Mail (2.1485) Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 18:06:20 -0000 On Aug 22, 2012, at 9:59 AM, denis.pinkas@bull.net wrote: > RFC 5280 states on page 69, section 5.3 : CRL Entry Extensions=20 >=20 > "If a CRL contains a critical CRL entry extension that the application = cannot > process, then the application MUST NOT use that CRL to determine the = status=20 > of any certificates".=20 >=20 > This should be changed into:=20 >=20 > "If a CRL contains a critical CRL entry extension that the application = cannot > process, then the application MUST NOT use that CRL entry to determine = the status=20 > of this certificate".=20 This proposed change seems horribly wrong. The change would mean that = there is no reason to mark a CRL entry extension as critical or not: the = two are the same. Further, you don't use CRL entry extensions to = determine the status of the certificate: you use them to determine the = nature of the CRL. Also, it is definitely a proposed change, not an errata. --Paul Hoffman= From SChokhani@cygnacom.com Wed Aug 22 11:20:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F1521F8539 for ; Wed, 22 Aug 2012 11:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HD-WAzsoy3e for ; Wed, 22 Aug 2012 11:20:23 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6230D21F8628 for ; Wed, 22 Aug 2012 11:20:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,809,1344225600"; d="scan'208";a="5983699" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 22 Aug 2012 14:20:10 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 22 Aug 2012 14:20:10 -0400 From: Santosh Chokhani To: Paul Hoffman , "pkix@ietf.org PKIX" Date: Wed, 22 Aug 2012 14:20:09 -0400 Thread-Topic: [pkix] Errata in section 5.3 from RFC 5280 Thread-Index: Ac2AkNkSUBobQ3FzRay7jYEkgICCnAAAXgzg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 18:20:24 -0000 I agree with Paul's conclusion, while I would rationalize it more logically= . Specifically, per Section 5.3.3, the certificate issuer not only impacts th= e entry in which it appears, but subsequent entries. Thus, adopting Denis'= s proposal can cause undesirable security issues. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Pau= l Hoffman Sent: Wednesday, August 22, 2012 2:06 PM To: pkix@ietf.org PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 On Aug 22, 2012, at 9:59 AM, denis.pinkas@bull.net wrote: > RFC 5280 states on page 69, section 5.3 : CRL Entry Extensions >=20 > "If a CRL contains a critical CRL entry extension that the application=20 > cannot process, then the application MUST NOT use that CRL to=20 > determine the status of any certificates". >=20 > This should be changed into:=20 >=20 > "If a CRL contains a critical CRL entry extension that the application=20 > cannot process, then the application MUST NOT use that CRL entry to=20 > determine the status of this certificate". This proposed change seems horribly wrong. The change would mean that there= is no reason to mark a CRL entry extension as critical or not: the two are= the same. Further, you don't use CRL entry extensions to determine the sta= tus of the certificate: you use them to determine the nature of the CRL. Also, it is definitely a proposed change, not an errata. --Paul Hoffman _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Wed Aug 22 13:46:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85D621F86D7 for ; Wed, 22 Aug 2012 13:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.157 X-Spam-Level: X-Spam-Status: No, score=-10.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFTrhZ3DLfVU for ; Wed, 22 Aug 2012 13:46:21 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1434321F86FC for ; Wed, 22 Aug 2012 13:46:20 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7MKkDJ3026685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Aug 2012 22:46:19 +0200 (MEST) In-Reply-To: To: denis.pinkas@bull.net Date: Wed, 22 Aug 2012 22:46:13 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 20:46:22 -0000 denis.pinkas@bull.net wrote: > RFC 5280 states on page 69, section 5.3 : CRL Entry Extensions > > "If a CRL contains a critical CRL entry extension that the application > cannot process, then the application MUST NOT use that CRL to > determine the status of any certificates". > > This should be changed into: > > "If a CRL contains a critical CRL entry extension that the application > cannot process, then the application MUST NOT use that CRL entry to > determine the status of this certificate". I'll note that your suggested replacement would create a security problem. First of all, this semantic has been present in the spec since rfc2459. Your suggested change would be backwards-incompatible and affect EVERY PKI implementation that implements CRL processing. You simply can not perform such a change to an installed base at this point in time. So I'm opposing your change. Curiously, ITU-T X.509 differs from PKIX (rfc2459->rfc5280) on the semantics when encountering an unrecognized critical CrlEntryExtension: (relevant parts prefixed with *>) As you may notice, X.509 does *NOT* specify, that the CRLEntry should be ignored when accompanied by a critical CRLEntryExtension. It would cause a security problem if it did. Quoting from ITU-T Tec. X.509 (08/2005), Section 7.3, top of page 18: *> NOTE 4 -- When an implementation processing a certificate revocation *> list does not recognize a critical extension in the crlEntryExtensions *> field, it shall assume that, at a minimum, the identified certificate *> has been revoked and is no longer valid and perform additional actions concerning that revoked certificate as dictated by local policy. When an implementation does not recognize a critical extension in the crlExtensions field, it shall assume that identified certificates have been revoked and are no longer valid. However in the latter case, since the list may not be complete, certificates that have not been identified as being revoked cannot be assumed to be valid. In this case local policy shall dictate the action to be taken. In any case local policy may dictate actions in addition to and/or stronger than those stated in this Specification. NOTE 5 -- If an extension affects the treatment of the list (e.g., multiple CRLs need to be scanned to examine the entire list of revoked certificates, or an entry may represent a range of certificates), then that extension shall be indicated as critical in the crlExtensions field regardless of where the extension is placed in the CRL. *> An extension indicated in the crlEntryExtensions field of an entry shall *> be placed in that entry and shall affect only the certificate(s) *> specified in that entry. Although I find the original X.509 semantics for processing CRLEntryExtensions much more reasonable than what rfc2459->rfc5280 says, I firmly believe that as IETF we can not retroactively change the semantics for processing critical CRLEntryExtensions for rfc2459->rfc5280 & implementations based on these (proposed) standards (in a backwards-incompatible fashion). -Martin From mrex@sap.com Wed Aug 22 20:38:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA4A21F8541 for ; Wed, 22 Aug 2012 20:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.158 X-Spam-Level: X-Spam-Status: No, score=-10.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0id5CyOUeGf0 for ; Wed, 22 Aug 2012 20:38:15 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9621521F8540 for ; Wed, 22 Aug 2012 20:38:15 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q7N3cCCg019831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Aug 2012 05:38:13 +0200 (MEST) In-Reply-To: To: denis.pinkas@bull.net Date: Thu, 23 Aug 2012 05:38:11 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120823033811.99A9A1A1A8@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 03:38:16 -0000 denis.pinkas@bull.net wrote: > > [Denis: returning the hash provides the same benefit. The > comparison will be done by the client rather than by the server]. Denis, you're (mostly) correct on "returning the hash". The presence of the certificate hash in the OCSP response in a non-critical(!) singleResponseExtension is vital for all scenarios where OCSP responses are processed without a prior OCSP request, i.e. all caching and all stapling and proxy scenarios. But I still believe that adding the hash into the request provides additional benefits, so I'd like to see both possibilities. Probably something like CertificateImprint ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, certificateHash OCTET STRING } plus an ASN.1 OID for wrapping it into an Extension... -Martin From denis.pinkas@bull.net Thu Aug 23 10:25:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1115C21F8609 for ; Thu, 23 Aug 2012 10:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFKFj4pVJSzI for ; Thu, 23 Aug 2012 10:25:22 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 803C121F855E for ; Thu, 23 Aug 2012 10:25:21 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id DF21F1809E; Thu, 23 Aug 2012 19:25:19 +0200 (CEST) In-Reply-To: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> To: mrex@sap.com, pkix@ietf.org MIME-Version: 1.0 X-KeepSent: 7212BDF4:EECB268F-C1257A63:005BBEF7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Thu, 23 Aug 2012 19:25:18 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 23/08/2012 19:25:19, Serialize complete at 23/08/2012 19:25:19 Content-Type: multipart/alternative; boundary="=_alternative 005F9154C1257A63_=" Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 17:25:23 -0000 Message en plusieurs parties au format MIME --=_alternative 005F9154C1257A63_= Content-Type: text/plain; charset="US-ASCII" Martin, Your email is quite interesting and I was not thinking that the discussion on OCSP would lead to look at CRLs as defined in X.509. Let me first say that RFC 2459 <--> RFC 5280 are supposed to be a *profile* of X.509, which means dropping some of its complexity, but not changing its semantics. RFC 2459 <--> RFC 5280 are clearly changing the semantics of the processing of crlEntryExtensions. Remainder: do not confuse crlEntryExtensions with crlExtensions. Let me put together the two paragraphs extracted from X.509 by Martin: NOTE 5 -- (...) An extension indicated in the crlEntryExtensions field of an entry shall be placed in that entry and shall affect only the certificate(s) specified in that entry. NOTE 4 -- When an implementation processing a certificate revocation list does not recognize a critical extension in the crlEntryExtensions field, it shall assume that, at a minimum, the identified certificate has been revoked and is no longer valid and perform additional actions concerning that revoked certificate as dictated by local policy. This validates my text proposal which still is: If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL entry to determine the status of this certificate". : The key question is : which text "makes sense" ? Using an example, let us see the implications using a CRL with 5000 entries. Using the text from X.509, when you look for the revocation status of a certificate in a CRL you look for the serial number of that certificate. If an entry contains that serial number, then you look also at that crlEntryExtensions (you process it) and you are done with a result. Using the text from RFC 5280, when you look for the revocation status of a certificate in a CRL, you need to look at each of the 5000 entries to see if there is a single crlEntryExtension that you don't understand and which is marked critical. If one exists, you can't determine the revocation status of that certificate, even if there is no single critical crlEntryExtension present in the entry which contains the serial number of that certificate. The text from X.509 makes sense, while the text from RFC 5280 does not. If we keep the current text from RFC 5280, then RFC 5280 is not compatible with X.509. This is a serious issue. Many calls for tenders request "X.509 compatibility" and also request RFC 5280 compatibility for convenience. How would it be possible to refer to two documents that are incompatible ? Denis > > > > "If a CRL contains a critical CRL entry extension that the application > > cannot process, then the application MUST NOT use that CRL to > > determine the status of any certificates". > > > > This should be changed into: > > > > "If a CRL contains a critical CRL entry extension that the application > > cannot process, then the application MUST NOT use that CRL entry to > > determine the status of this certificate". > > I'll note that your suggested replacement would create a security problem. > > First of all, this semantic has been present in the spec since rfc2459. > Your suggested change would be backwards-incompatible and affect EVERY > PKI implementation that implements CRL processing. You simply > can not perform such a change to an installed base at this point in time. > > So I'm opposing your change. > > Curiously, ITU-T X.509 differs from PKIX (rfc2459->rfc5280) on the > semantics when encountering an unrecognized critical CrlEntryExtension: > (relevant parts prefixed with *>) > > As you may notice, X.509 does *NOT* specify, that the CRLEntry should > be ignored when accompanied by a critical CRLEntryExtension. It would > cause a security problem if it did. > > Quoting from ITU-T Tec. X.509 (08/2005), Section 7.3, top of page 18: > > *> NOTE 4 -- When an implementation processing a certificate revocation > *> list does not recognize a critical extension in the crlEntryExtensions > *> field, it shall assume that, at a minimum, the identified certificate > *> has been revoked and is no longer valid and perform additional actions > concerning that revoked certificate as dictated by local policy. > When an implementation does not recognize a critical extension in the > crlExtensions field, it shall assume that identified certificates > have been revoked and are no longer valid. However in the latter case, > since the list may not be complete, certificates that have not been > identified as being revoked cannot be assumed to be valid. In this case > local policy shall dictate the action to be taken. In any case local > policy may dictate actions in addition to and/or stronger than those > stated in this Specification. > > NOTE 5 -- If an extension affects the treatment of the list > (e.g., multiple CRLs need to be scanned to examine the entire list of > revoked certificates, or an entry may represent a range of certificates), > then that extension shall be indicated as critical in the crlExtensions > field regardless of where the extension is placed in the CRL. > *> An extension indicated in the crlEntryExtensions field of an entry shall > *> be placed in that entry and shall affect only the certificate(s) > *> specified in that entry. > > > Although I find the original X.509 semantics for processing > CRLEntryExtensions much more reasonable than what rfc2459->rfc5280 says, > I firmly believe that as IETF we can not retroactively change the > semantics for processing critical CRLEntryExtensions for > rfc2459->rfc5280 & implementations based on these (proposed) standards > (in a backwards-incompatible fashion). > > > -Martin --=_alternative 005F9154C1257A63_= Content-Type: text/html; charset="US-ASCII" Martin,

Your email is quite interesting and I was not thinking that the discussion on OCSP would lead
to look at CRLs as defined in  X.509.

Let me first say that RFC  2459 <--> RFC 5280 are supposed to be a *profile* of X.509,
which means dropping some of its complexity, but not changing its semantics.

RFC  2459 <--> RFC 5280 are clearly changing the semantics of the processing of crlEntryExtensions.

Remainder: do not confuse crlEntryExtensions with crlExtensions.

Let me put together the two paragraphs extracted from X.509 by Martin:

NOTE 5 -- (...)
         An extension indicated in the crlEntryExtensions field of an entry shall
         be placed in that entry and shall affect only the certificate(s)
         specified in that entry.

NOTE 4 -- When an implementation processing a certificate revocation
         list does not recognize a critical extension in the crlEntryExtensions
         field, it shall assume that, at a minimum, the identified certificate
         has been revoked and is no longer valid and perform additional actions
         concerning that revoked certificate as dictated by local policy.

This validates my text proposal which still is:

   If a CRL contains a critical CRL entry extension that the application
  cannot process, then the application MUST NOT use that CRL entry to
  determine the status of this certificate". :

The key question is : which text "makes sense" ?

Using an example, let us see the implications using a CRL with 5000 entries.

Using the text from X.509, when you look for the revocation status of a certificate in a CRL you look
for the serial number of that certificate. If an entry contains that serial number,  then you look also
at that crlEntryExtensions (you process it) and you are done with a result.

Using the text from RFC 5280, when you look for the revocation status of a certificate in a CRL, you need
to look at each of the 5000 entries to see if there is a single crlEntryExtension that
you don't understand and which is marked critical. If one exists, you can't determine the revocation status
of that certificate, even if there is no single critical crlEntryExtension  present in the entry which contains
the serial number of that certificate.

The text from X.509 makes sense, while the text from RFC 5280 does not.

 If we keep the current text from RFC 5280, then RFC 5280 is not compatible with X.509.

This is a serious issue.

Many calls for tenders request "X.509 compatibility" and also request RFC 5280 compatibility for convenience.
How would it be possible to refer to two documents that are incompatible ?

Denis  

> >
> >   "If a CRL contains a critical CRL entry extension that the application
> >   cannot process, then the application MUST NOT use that CRL to
> >   determine the status of any certificates".
> >
> > This should be changed into:
> >
> >   "If a CRL contains a critical CRL entry extension that the application
> >   cannot process, then the application MUST NOT use that CRL entry to
> >   determine the status of this certificate".
>
> I'll note that your suggested replacement would create a security problem.
>
> First of all, this semantic has been present in the spec since rfc2459.
> Your suggested change would be backwards-incompatible and affect EVERY
> PKI implementation that implements CRL processing.  You simply
> can not perform such a change to an installed base at this point in time.
>
> So I'm opposing your change.
>
> Curiously, ITU-T X.509 differs from PKIX (rfc2459->rfc5280) on the
> semantics when encountering an unrecognized critical CrlEntryExtension:
> (relevant parts prefixed with *>)
>
> As you may notice, X.509 does *NOT* specify, that the CRLEntry should
> be ignored when accompanied by a critical CRLEntryExtension.  It would
> cause a security problem if it did.
>
> Quoting from ITU-T Tec. X.509 (08/2005), Section 7.3, top of page 18:
>
> *>  NOTE 4 -- When an implementation processing a certificate revocation
> *>  list does not recognize a critical extension in the crlEntryExtensions
> *>  field, it shall assume that, at a minimum, the identified certificate
> *>  has been revoked and is no longer valid and perform additional actions
>     concerning that revoked certificate as dictated by local policy.
>     When an implementation does not recognize a critical extension in the
>     crlExtensions field, it shall assume that identified certificates
>     have been revoked and are no longer valid. However in the latter case,
>     since the list may not be complete, certificates that have not been
>     identified as being revoked cannot be assumed to be valid. In this case
>     local policy shall dictate the action to be taken. In any case local
>     policy may dictate actions in addition to and/or stronger than those
>     stated in this Specification.
>
>     NOTE 5 -- If an extension affects the treatment of the list
>     (e.g., multiple CRLs need to be scanned to examine the entire list of
>     revoked certificates, or an entry may represent a range of certificates),
>     then that extension shall be indicated as critical in the crlExtensions
>     field regardless of where the extension is placed in the CRL.
> *>  An extension indicated in the crlEntryExtensions field of an entry shall
> *>  be placed in that entry and shall affect only the certificate(s)
> *>  specified in that entry.
>
>
> Although I find the original X.509 semantics for processing
> CRLEntryExtensions much more reasonable than what rfc2459->rfc5280 says,
> I firmly believe that as IETF we can not retroactively change the
> semantics for processing critical CRLEntryExtensions for
> rfc2459->rfc5280 & implementations based on these (proposed) standards
> (in a backwards-incompatible fashion).
>
>
> -Martin
 --=_alternative 005F9154C1257A63_=-- From richard.smith@comodo.com Thu Aug 23 12:32:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644A921F86A8 for ; Thu, 23 Aug 2012 12:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQu-S4PYDch0 for ; Thu, 23 Aug 2012 12:32:10 -0700 (PDT) Received: from mail.nj.office.comodo.net (mail.nj.office.comodo.net [38.104.66.254]) by ietfa.amsl.com (Postfix) with ESMTP id A914621F8665 for ; Thu, 23 Aug 2012 12:32:09 -0700 (PDT) Received: (qmail 16157 invoked by uid 1012); 23 Aug 2012 19:32:02 -0000 Received: from cgijc1dwwi1a5.comodo.net (HELO CGIJC1DWWI1A5) (192.168.65.48) by mail.nj.office.comodo.net (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Thu, 23 Aug 2012 15:32:02 -0400 From: "Rich Smith" To: , , References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> In-Reply-To: Date: Thu, 23 Aug 2012 15:32:00 -0400 Organization: Comodo Group, Inc. Message-ID: <045e01cd8165$f8476180$e8d62480$@smith@comodo.com> X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2BVFBqtJgl4kmlS32xDdb7jkB54AAEJrzA MIME-Version: 1.0 Content-Language: en-us Content-Type: multipart/signed; boundary="----=_NextPart_000_0456_01CD8144.705ACAD0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-Virus-Checked: Checked by ClamAV on mail.nj.office.comodo.net Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: richard.smith@comodo.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 19:32:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0456_01CD8144.705ACAD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0457_01CD8144.705ACAD0" ------=_NextPart_001_0457_01CD8144.705ACAD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree with Denis 100% and would go a step further and modify his suggested wording to: If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL entry <+>extension to determine the status of this certificate". If the certificate appears in the CRL it should be treated as revoked, whether or not the client can process any entry extensions. That is what is stated by x.509 as quoted by Martin and I fail to see an instance in which doing otherwise would make any sense. -- Regards, Rich Smith From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net Sent: Thursday, August 23, 2012 1:25 PM To: mrex@sap.com; pkix@ietf.org Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 Martin, Your email is quite interesting and I was not thinking that the discussion on OCSP would lead to look at CRLs as defined in X.509. Let me first say that RFC 2459 <--> RFC 5280 are supposed to be a *profile* of X.509, which means dropping some of its complexity, but not changing its semantics. RFC 2459 <--> RFC 5280 are clearly changing the semantics of the processing of crlEntryExtensions. Remainder: do not confuse crlEntryExtensions with crlExtensions. Let me put together the two paragraphs extracted from X.509 by Martin: NOTE 5 -- (...) An extension indicated in the crlEntryExtensions field of an entry shall be placed in that entry and shall affect only the certificate(s) specified in that entry. NOTE 4 -- When an implementation processing a certificate revocation list does not recognize a critical extension in the crlEntryExtensions field, it shall assume that, at a minimum, the identified certificate has been revoked and is no longer valid and perform additional actions concerning that revoked certificate as dictated by local policy. This validates my text proposal which still is: If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL entry to determine the status of this certificate". : The key question is : which text "makes sense" ? Using an example, let us see the implications using a CRL with 5000 entries. Using the text from X.509, when you look for the revocation status of a certificate in a CRL you look for the serial number of that certificate. If an entry contains that serial number, then you look also at that crlEntryExtensions (you process it) and you are done with a result. Using the text from RFC 5280, when you look for the revocation status of a certificate in a CRL, you need to look at each of the 5000 entries to see if there is a single crlEntryExtension that you don't understand and which is marked critical. If one exists, you can't determine the revocation status of that certificate, even if there is no single critical crlEntryExtension present in the entry which contains the serial number of that certificate. The text from X.509 makes sense, while the text from RFC 5280 does not. If we keep the current text from RFC 5280, then RFC 5280 is not compatible with X.509. This is a serious issue. Many calls for tenders request "X.509 compatibility" and also request RFC 5280 compatibility for convenience. How would it be possible to refer to two documents that are incompatible ? Denis > > > > "If a CRL contains a critical CRL entry extension that the application > > cannot process, then the application MUST NOT use that CRL to > > determine the status of any certificates". > > > > This should be changed into: > > > > "If a CRL contains a critical CRL entry extension that the application > > cannot process, then the application MUST NOT use that CRL entry to > > determine the status of this certificate". > > I'll note that your suggested replacement would create a security problem. > > First of all, this semantic has been present in the spec since rfc2459. > Your suggested change would be backwards-incompatible and affect EVERY > PKI implementation that implements CRL processing. You simply > can not perform such a change to an installed base at this point in time. > > So I'm opposing your change. > > Curiously, ITU-T X.509 differs from PKIX (rfc2459->rfc5280) on the > semantics when encountering an unrecognized critical CrlEntryExtension: > (relevant parts prefixed with *>) > > As you may notice, X.509 does *NOT* specify, that the CRLEntry should > be ignored when accompanied by a critical CRLEntryExtension. It would > cause a security problem if it did. > > Quoting from ITU-T Tec. X.509 (08/2005), Section 7.3, top of page 18: > > *> NOTE 4 -- When an implementation processing a certificate revocation > *> list does not recognize a critical extension in the crlEntryExtensions > *> field, it shall assume that, at a minimum, the identified certificate > *> has been revoked and is no longer valid and perform additional actions > concerning that revoked certificate as dictated by local policy. > When an implementation does not recognize a critical extension in the > crlExtensions field, it shall assume that identified certificates > have been revoked and are no longer valid. However in the latter case, > since the list may not be complete, certificates that have not been > identified as being revoked cannot be assumed to be valid. In this case > local policy shall dictate the action to be taken. In any case local > policy may dictate actions in addition to and/or stronger than those > stated in this Specification. > > NOTE 5 -- If an extension affects the treatment of the list > (e.g., multiple CRLs need to be scanned to examine the entire list of > revoked certificates, or an entry may represent a range of certificates), > then that extension shall be indicated as critical in the crlExtensions > field regardless of where the extension is placed in the CRL. > *> An extension indicated in the crlEntryExtensions field of an entry shall > *> be placed in that entry and shall affect only the certificate(s) > *> specified in that entry. > > > Although I find the original X.509 semantics for processing > CRLEntryExtensions much more reasonable than what rfc2459->rfc5280 says, > I firmly believe that as IETF we can not retroactively change the > semantics for processing critical CRLEntryExtensions for > rfc2459->rfc5280 & implementations based on these (proposed) standards > (in a backwards-incompatible fashion). > > > -Martin ------=_NextPart_001_0457_01CD8144.705ACAD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Denis 100% and would go a step further and modify his = suggested wording to:

   If a = CRL contains a critical CRL entry extension that the application =
  cannot process, then the application MUST NOT use = that CRL entry <+>extension</+> to
  = determine the status of this certificate".

 

If the certificate appears in the CRL it should be treated as = revoked, whether or not the client can process any entry = extensions.  That is what is stated by x.509 as quoted by Martin = and I fail to see an instance in which doing otherwise would make any = sense.

 

--=

Re= gards,

Ri= ch Smith

 

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = denis.pinkas@bull.net
Sent: Thursday, August 23, 2012 1:25 = PM
To: mrex@sap.com; pkix@ietf.org
Subject: Re: = [pkix] Errata in section 5.3 from RFC = 5280

 

Martin,

Your email = is quite interesting and I was not thinking that the discussion on OCSP = would lead
to look at = CRLs as defined in  X.509.

Let me first = say that RFC  2459 <--> RFC 5280 are supposed to be a = *profile* of X.509,
which means dropping some of its complexity, but = not changing its semantics.

RFC =  2459 <--> RFC 5280 are clearly changing the semantics of the = processing of crlEntryExtensions. =

Remainder: do not confuse = crlEntryExtensions with crlExtensions.

Let me put together the two paragraphs = extracted from X.509 by Martin:

NOTE 5 -- (...)
  =        An extension indicated in the = crlEntryExtensions field of an entry shall
    =      be placed in that entry and shall affect only the = certificate(s)
         specified = in that entry.

NOTE 4 -- When an implementation processing a = certificate revocation
  =        list does not recognize a critical extension = in the crlEntryExtensions
        =  field, it shall assume that, at a minimum, the identified = certificate
         has been = revoked and is no longer valid and perform additional = actions
         concerning that = revoked certificate as dictated by local policy. =

This = validates my text proposal which still is:

   If a CRL contains a critical CRL = entry extension that the application
  = cannot process, then the application MUST NOT use that CRL entry = to
  determine the status of this certificate". = : =

The key = question is : which text "makes sense" ?

Using an = example, let us see the implications using a CRL with 5000 = entries.

Using the = text from X.509, when you look for the revocation status of a = certificate in a CRL you look
for the = serial number of that certificate. If an entry contains that serial = number,  then you look also
at that = crlEntryExtensions (you = process it) and you are done with a result.

Using the = text from RFC 5280, when you look for the revocation status of a = certificate in a CRL, you need
to look at = each of the 5000 entries to see if there is a single crlEntryExtension that =
you don't = understand and which is marked critical. If one exists, you can't = determine the revocation status
of that certificate, even if there = is no single critical crlEntryExtension =  present in the entry which contains
the serial number of that = certificate.

The text = from X.509 makes sense, while the text from RFC 5280 does not. =

 If we = keep the current text from RFC 5280, then RFC 5280 is not compatible = with X.509.

This is a = serious issue.

Many calls = for tenders request "X.509 compatibility" and also request RFC = 5280 compatibility for convenience.
How would it = be possible to refer to two documents that are incompatible ? =

Denis =  

> > =
> >   "If a CRL contains a critical CRL = entry extension that the application
> >   = cannot process, then the application MUST NOT use that CRL = to
> >   determine the status of any = certificates".
> >
> > This = should be changed into:
> >
> > =   "If a CRL contains a critical CRL entry extension that the = application
> >   cannot process, then the = application MUST NOT use that CRL entry to
> >   = determine the status of this certificate".
> =
> I'll note that your suggested replacement would create = a security problem.
>
> First of all, = this semantic has been present in the spec since = rfc2459.
> Your suggested change would be = backwards-incompatible and affect EVERY
> PKI = implementation that implements CRL processing.  You = simply
> can not perform such a change to an installed = base at this point in time.
>
> So I'm = opposing your change.
>
> Curiously, = ITU-T X.509 differs from PKIX (rfc2459->rfc5280) on = the
> semantics when encountering an unrecognized = critical CrlEntryExtension:
> (relevant parts prefixed = with *>)
>
> As you may notice, X.509 = does *NOT* specify, that the CRLEntry should
> be ignored = when accompanied by a critical CRLEntryExtension.  It = would
> cause a security problem if it = did.
>
> Quoting from ITU-T Tec. X.509 = (08/2005), Section 7.3, top of page 18:
> =
> *>  NOTE 4 -- When an implementation = processing a certificate revocation
> *>  list = does not recognize a critical extension in the = crlEntryExtensions
> *>  field, it shall assume = that, at a minimum, the identified certificate
> *> =  has been revoked and is no longer valid and perform additional = actions
>     concerning that revoked = certificate as dictated by local policy.
>     = When an implementation does not recognize a critical extension in = the
>     crlExtensions field, it shall assume = that identified certificates
>     have been = revoked and are no longer valid. However in the latter = case,
>     since the list may not be complete, = certificates that have not been
>     = identified as being revoked cannot be assumed to be valid. In this = case
>     local policy shall dictate the = action to be taken. In any case local
>     = policy may dictate actions in addition to and/or stronger than = those
>     stated in this = Specification.
>
>     NOTE 5 = -- If an extension affects the treatment of the list
> =     (e.g., multiple CRLs need to be scanned to examine the = entire list of
>     revoked certificates, or = an entry may represent a range of certificates),
>   =   then that extension shall be indicated as critical in the = crlExtensions
>     field regardless of where = the extension is placed in the CRL.
> *>  An = extension indicated in the crlEntryExtensions field of an entry = shall
> *>  be placed in that entry and shall = affect only the certificate(s)
> *>  specified in = that entry.
>
>
> = Although I find the original X.509 semantics for = processing
> CRLEntryExtensions much more reasonable than = what rfc2459->rfc5280 says,
> I firmly believe that as = IETF we can not retroactively change the
> semantics for = processing critical CRLEntryExtensions for
> = rfc2459->rfc5280 & implementations based on these (proposed) = standards
> (in a backwards-incompatible = fashion).
>
>
> = -Martin

------=_NextPart_001_0457_01CD8144.705ACAD0-- ------=_NextPart_000_0456_01CD8144.705ACAD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUUTCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFGjCCBAKgAwIBAgIQbRnq pxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU 4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHff sReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kAB W0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJk JpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IB SzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4 Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVu dF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcN AQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjB MCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8 H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5 OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggZUMIIFPKADAgECAhEAqDR0 NPXZ6UURhku5W7S0lTANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdy ZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF bWFpbCBDQTAeFw0xMTA2MTAwMDAwMDBaFw0xNDA2MDkyMzU5NTlaMIIBKTELMAkGA1UEBhMCVVMx DjAMBgNVBBETBTA3MzEwMQswCQYDVQQIEwJOSjEUMBIGA1UEBxMLSmVyc2V5IENpdHkxEjAQBgNV BAkTCVN1aXRlMTQwMDEcMBoGA1UECRMTNTI1IFdhc2hpbmd0b24gQmx2ZDEaMBgGA1UEChMRQ29t b2RvIEdyb3VwIEluYy4xNzA1BgNVBAsTLklzc3VlZCB0aHJvdWdoIENvbW9kbyBHcm91cCBJbmMu IEUtUEtJIE1hbmFnZXIxHzAdBgNVBAsTFkNvcnBvcmF0ZSBTZWN1cmUgRW1haWwxFjAUBgNVBAMT DVJpY2hhcmQgU21pdGgxJzAlBgkqhkiG9w0BCQEWGHJpY2hhcmQuc21pdGhAY29tb2RvLmNvbTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALMPjP+Ri13hHVrQkDXKpGcoQKrjJ6qGLrOy fTCeyOLlxU0Xk362WTnYfUjDlMBppwDGIFqboM8EwlFr9xh5vhUULy4uU5oiEQeLoDGxVsmmxCZ7 OR2TBdFt9b8YizN01/QeAVbj8JSFtWwiwFtntLEAg8DIG2+Vw/LYxYs8LaT6XySFCX/tCZJSurAO VLIr83xT3yxySkOM0iCXk450FPFSGUaIL1k7oxRgiMD7m8Sj3bHgkT1EZfIcuZVcJfoeqAT1XHlj G6ewQIfStVb2JNTeuIxmu2HDvjdAEVN0bvyVvMoeWpLtAvrI1/VDZzBiwgcTmBjCh2Bt/hLvtbKh fUMCAwEAAaOCAggwggIEMB8GA1UdIwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQW BBS68Ixj5XXWDJB8tE3V+7n7k0gEXjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADApBgNV HSUEIjAgBggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcUAgIwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAwUwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYD VR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAC hkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl Y3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wTQYD VR0RBEYwRIEYcmljaGFyZC5zbWl0aEBjb21vZG8uY29toCgGCisGAQQBgjcUAgOgGgwYcmljaGFy ZC5zbWl0aEBjb21vZG8uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAFmeOXSnZsiT8YXbkbodhT82mh 3FvMKehuDnAD6t5f+MeEOUthUw4SCSHM2kCCVUzNeZ3qFsLA1oCJ/PCgwXgwkmPoHaBk8RBteGp2 E6IVrnlJ4QzCfY5h31uhQo7qxcnm0OEpSSIOd/xRyh/LV4I6+qLZz4aB0/FfBV3WaDOfkzuBOYGU kVD0A8lKCIZIbmvhcte5U+6LIrh7suu96RmWwHvAaCBNF7qNEgX20KEtHdW+1IPeNO2C6LlRMcOl zi4pXyc/gD09AaEGI9vMlG/Q81pyHwccUWDVQ+29zjsQ9s4o7q/waHHeuBBnND8YWqGbMrk8DcdJ tqWU3RQ5XaUsMYIEaDCCBGQCAQEwgakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCoNHQ09dnpRRGGS7lbtLSVMAkGBSsOAwIaBQCgggKTMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgyMzE5MzIwMFowIwYJKoZIhvcNAQkEMRYEFFPKvz/z XSM8WvXMkpQnzG48jgbrMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgB ZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMIG6BgkrBgEEAYI3EAQxgawwgakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCoNHQ09dnpRRGGS7lbtLSVMIG8BgsqhkiG 9w0BCRACCzGBrKCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMT MENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAKg0dDT1 2elFEYZLuVu0tJUwDQYJKoZIhvcNAQEBBQAEggEAeEeR7vhsEa40gZuccn+fJpqj5G7RNoUPATWz fVqd8a4BMnP9hHfHUVcpYAR58Q2qTlx6WnozNW35PF54W6K/xT5aWr6vH7dOVeUvAQB+VAbCS/eZ zxVrzsHPRWvmgCtdDA62UDb379ZHYbQvpY11hwuQG+JEpAhc37j2e/2kRGq93kKOOrXLzQmvUhB+ 5IdJA/CcamKGwJnHIpJYr0c8nrSBf5mvnP0XQpotydWkHbmrNN93on30otg7mquTyvIArdH6WPBL GlVCy/ESvxc5U0wFWXNgDq5U+fXAvlY8PeT20HLlrNFfT6IutOtNRE/usu8h5rOp77UJz6lFhP4P jwAAAAAAAA== ------=_NextPart_000_0456_01CD8144.705ACAD0-- From housley@vigilsec.com Thu Aug 23 12:50:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994DF21F86A4 for ; Thu, 23 Aug 2012 12:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6FAQXFIrt3x for ; Thu, 23 Aug 2012 12:50:15 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id D5F9421F86BA for ; Thu, 23 Aug 2012 12:50:14 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E42CA9A4003; Thu, 23 Aug 2012 15:50:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id QEcqUUpd2nvt; Thu, 23 Aug 2012 15:50:07 -0400 (EDT) Received: from [192.168.1.3] (96-37-2-47.dhcp.sffl.va.charter.com [96.37.2.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 17D6E9A4002; Thu, 23 Aug 2012 15:50:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-133-224508247 From: Russ Housley In-Reply-To: Date: Thu, 23 Aug 2012 15:50:11 -0400 Message-Id: <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> To: denis.pinkas@bull.net X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 19:50:18 -0000 --Apple-Mail-133-224508247 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I agree with the proposal that Denis makes. I support his proposed text. > This validates my text proposal which still is: > > If a CRL contains a critical CRL entry extension that the application > cannot process, then the application MUST NOT use that CRL entry to > determine the status of this certificate". : Russ --Apple-Mail-133-224508247 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This validates my text proposal which = still is: 

   If a CRL contains a critical CRL entry extension = that the application 
  cannot process, = then the application MUST NOT use that CRL entry to
  determine = the status of this certificate". : 
Russ
= --Apple-Mail-133-224508247-- From SChokhani@cygnacom.com Thu Aug 23 13:01:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE97321F8634 for ; Thu, 23 Aug 2012 13:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpyERAdOxiwJ for ; Thu, 23 Aug 2012 13:01:19 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4B821F861E for ; Thu, 23 Aug 2012 13:01:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,301,1344225600"; d="scan'208,217";a="1719654" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 23 Aug 2012 16:01:17 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 23 Aug 2012 16:01:17 -0400 From: Santosh Chokhani To: Russ Housley , "denis.pinkas@bull.net" Date: Thu, 23 Aug 2012 16:01:16 -0400 Thread-Topic: [pkix] Errata in section 5.3 from RFC 5280 Thread-Index: Ac2BaIqMavL/cr54RYOHYhL1cHKVzwAANcXg Message-ID: References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> In-Reply-To: <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF36299E28scygexch7cygnac_" MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 20:01:21 -0000 --_000_B83745DA469B7847811819C5005244AF36299E28scygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Russ, The problem with Denis's proposal is that he wants to replace the text of n= ot using the CRL. I have cited a specific example in 5280 itself where an entry extension sco= pe goes beyond that of the entry. It potentially impacts subsequent entrie= s. Thus, Denis's proposal is unacceptable. If he just wanted to add the sente= nce as opposed to replace, it would be fine. In general, unless 5280 and X.509 stated that an entry extension cannot imp= act semantics of anything in the CRL other than the entry itself, what you = say is unacceptable and potentially insecure. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Thursday, August 23, 2012 3:50 PM To: denis.pinkas@bull.net Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 I agree with the proposal that Denis makes. I support his proposed text. This validates my text proposal which still is: If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL entry to determine the status of this certificate". : Russ --_000_B83745DA469B7847811819C5005244AF36299E28scygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Russ,

 

The problem with Denis’s proposal is that he wants = to replace the text of not using the CRL.

 

I have = cited a specific example in 5280 itself where an entry extension scope goes= beyond that of the entry.  It potentially impacts subsequent entries.=

 

=

Thus, Denis’s proposal is unacceptable. = ; If he just wanted to add the sentence as opposed to replace, it would be = fine.

 

In general, unless 5280 and X.509 stated that= an entry extension cannot impact semantics of anything in the CRL other th= an the entry itself, what you say is unacceptable and potentially insecure.=

 

=

From: pkix-bounces@ietf.org [mailto:pkix-b= ounces@ietf.org] On Behalf Of Russ Housley
Sent: Thursday,= August 23, 2012 3:50 PM
To: denis.pinkas@bull.net
Cc: = IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280=

 

 

I= agree with the proposal that Denis makes.  I support his proposed tex= t.

 

This validates my text proposal which still is:=  

=    If a CRL contains a criti= cal CRL entry extension that the application 
  cannot process, then the application MUST NOT use that = CRL entry to
  determine the status of this certificate&qu= ot;. : 

 

Russ

= --_000_B83745DA469B7847811819C5005244AF36299E28scygexch7cygnac_-- From housley@vigilsec.com Thu Aug 23 13:15:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AA621F84E4 for ; Thu, 23 Aug 2012 13:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B769au6YXpZ5 for ; Thu, 23 Aug 2012 13:15:17 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 23BFC21F84E7 for ; Thu, 23 Aug 2012 13:15:17 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 1FBD59A4003; Thu, 23 Aug 2012 16:15:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id bZuA-eO9NBrg; Thu, 23 Aug 2012 16:15:10 -0400 (EDT) Received: from [192.168.1.3] (96-37-2-47.dhcp.sffl.va.charter.com [96.37.2.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 77AA79A4002; Thu, 23 Aug 2012 16:15:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-137-226008713 From: Russ Housley In-Reply-To: Date: Thu, 23 Aug 2012 16:15:12 -0400 Message-Id: References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> To: Santosh Chokhani X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 20:15:18 -0000 --Apple-Mail-137-226008713 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Santosh: RFC 5280 describes three CRL Entry Extensions, and all of them come from = X.509: 5.3.1. Reason Code 5.3.2. Invalidity Date 5.3.3. Certificate Issuer The first two do not have the concern that you describe, and the third = one should only be present if the CRL includes the = IssuingDistributionPoint CRL extension, and that extension includes the = indirectCRL set to TRUE. The IssuingDistributionPoint CRL extension = must be critical. RFC 5280 says: The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. To my mind, the support for the critical IssuingDistributionPoint CRL = extension includes the proper support for the Certificate Issuer CRL = entry extension. Russ On Aug 23, 2012, at 4:01 PM, Santosh Chokhani wrote: > Russ, > =20 > The problem with Denis=92s proposal is that he wants to replace the = text of not using the CRL. > =20 > I have cited a specific example in 5280 itself where an entry = extension scope goes beyond that of the entry. It potentially impacts = subsequent entries. > =20 > Thus, Denis=92s proposal is unacceptable. If he just wanted to add = the sentence as opposed to replace, it would be fine. > =20 > In general, unless 5280 and X.509 stated that an entry extension = cannot impact semantics of anything in the CRL other than the entry = itself, what you say is unacceptable and potentially insecure. > =20 > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Russ Housley > Sent: Thursday, August 23, 2012 3:50 PM > To: denis.pinkas@bull.net > Cc: IETF PKIX > Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 > =20 > =20 > I agree with the proposal that Denis makes. I support his proposed = text. > =20 > This validates my text proposal which still is:=20 >=20 > If a CRL contains a critical CRL entry extension that the = application=20 > cannot process, then the application MUST NOT use that CRL entry to > determine the status of this certificate". :=20 > =20 > Russ --Apple-Mail-137-226008713 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 5.3.1.  Reason = Code
= 5.3.2.  Invalidity Date
5.3.3. =  Certificate Issuer

The first two do not = have the concern that you describe, and the third one should only be = present if the CRL includes the IssuingDistributionPoint CRL = extension, and that extension includes the indirectCRL set to TRUE. =  The IssuingDistributionPoint CRL extension must be critical. =  RFC 5280 says:

   The = issuing distribution point is a critical CRL extension = that
   identifies the CRL distribution point and = scope for a particular CRL,
   and it indicates = whether the CRL covers revocation for end entity
  =  certificates only, CA certificates only, attribute certificates = only,
   or a limited set of reason codes. =  Although the extension is
   critical, = conforming implementations are not required to support = this
   extension.  However, implementations = that do not support this
   extension MUST either = treat the status of any certificate not listed
   on = this CRL as unknown or locate another CRL that does not = contain
   any unrecognized critical = extensions.

To my mind, the support for = the critical IssuingDistributionPoint CRL extension includes the proper = support for the Certificate Issuer CRL entry = extension.

Russ


On Aug 23, 2012, at 4:01 PM, Santosh Chokhani = wrote:

Russ,
The = problem with Denis=92s proposal is that he wants to replace the text of = not using the CRL.
I have = cited a specific example in 5280 itself where an entry extension scope = goes beyond that of the entry.  It potentially impacts subsequent = entries.
Thus, = Denis=92s proposal is unacceptable.  If he just wanted to add the = sentence as opposed to replace, it would be = fine.
In = general, unless 5280 and X.509 stated that an entry extension cannot = impact semantics of anything in the CRL other than the entry itself, = what you say is unacceptable and potentially = insecure.
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org= ] On Behalf Of Russ = Housley
Sent: Thursday, August 23, 2012 = 3:50 PM
To:  IETF = PKIX
Subject: Re: [pkix] Errata in = section 5.3 from RFC 5280
 
I agree with the proposal = that Denis makes.  I support his proposed = text.
This = validates my text proposal which still is:    If a CRL contains a critical = CRL entry extension that the application 
  cannot process, then the = application MUST NOT use that CRL entry to
  determine the status of = this certificate". : 
Date: Thu, 23 Aug 2012 14:05:47 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-caa-12.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 21:05:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource= Record Author(s) : Phillip Hallam-Baker Rob Stradling Filename : draft-ietf-pkix-caa-12.txt Pages : 17 Date : 2012-08-23 Abstract: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-caa There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-caa-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-caa-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hallam@gmail.com Thu Aug 23 14:12:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5352121F8607 for ; Thu, 23 Aug 2012 14:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.471 X-Spam-Level: X-Spam-Status: No, score=-5.471 tagged_above=-999 required=5 tests=[AWL=-1.872, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVtvlXKoz8Na for ; Thu, 23 Aug 2012 14:12:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9EDE21F8525 for ; Thu, 23 Aug 2012 14:12:35 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3277579obb.31 for ; Thu, 23 Aug 2012 14:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=sJKBuXKJihkso684KP9X10BAbndN5CHk6UxQgA1eYls=; b=dNZeVVq/JKJWu8kLhR1a1Q46E3i3RWj6odQMjLOLZcVBwcu+TYC2UvanD1ySIGya7d jkHAVTB8rNPpr6DrROymS42VjcxCrafHCvEhDv5qvNJtFYCAbzeWr0KtG0Vw07TL+vFB NkI9VLL6SpTtLoA6dIzEGof+WRJQ0x0a+peGKaDHBMnZ6VbVOoqlzQiz2yGQQ2e7cVzE vrgy385fbPsATCes6Xv9tH6konIDY2+/TcT/oX9sraxut0oJuMqo6euiWSVEMlaQHgih JatmR7Tbij7GaUm9uXWXWk46uLnDBa3BeJoFfIlIV8Xhcf2jnlHF52kUif7pj/qBn5t4 Vsdg== MIME-Version: 1.0 Received: by 10.60.29.72 with SMTP id i8mr2233463oeh.26.1345756355292; Thu, 23 Aug 2012 14:12:35 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Thu, 23 Aug 2012 14:12:35 -0700 (PDT) Date: Thu, 23 Aug 2012 17:12:35 -0400 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org, Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Subject: [pkix] Update to CAA spec X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 21:12:36 -0000 http://www.ietf.org/id/draft-ietf-pkix-caa-12.txt I have made what I hope is most of the edits required in response to the IESG, APPs and DNS reviews. The main substantive change here is that the old discovery algorithm is completely gone and it is replaced with a functional specification which I hope is more precise and easier to read. In the process of doing that I removed the language referring to the issuer authorization set and replaced it with 'relevant CAA record set' which I hope is easier to follow. One issue that might be argued over is which order a CA should follow aliases and search up the chain. As the draft stands is says, follow the alias first and if that is empty then look in the domain above. I suspect that it makes no difference which is done provided everyone does the same thing. -- Website: http://hallambaker.com/ From paul.hoffman@vpnc.org Thu Aug 23 14:44:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D017221F85D5 for ; Thu, 23 Aug 2012 14:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30L9Z7PmUfHo for ; Thu, 23 Aug 2012 14:44:11 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 008F221F85F9 for ; Thu, 23 Aug 2012 14:44:09 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7NLi4DO034202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Aug 2012 14:44:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Paul Hoffman In-Reply-To: <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> Date: Thu, 23 Aug 2012 14:44:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1485) Cc: IETF PKIX Subject: [pkix] Proposed change in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 21:44:12 -0000 On Aug 23, 2012, at 12:50 PM, Russ Housley wrote: >=20 > I agree with the proposal that Denis makes. I support his proposed = text. >=20 >> This validates my text proposal which still is:=20 >>=20 >> If a CRL contains a critical CRL entry extension that the = application=20 >> cannot process, then the application MUST NOT use that CRL entry to >> determine the status of this certificate". :=20 Can you say why? As you said in your later message, only = CertificateIssuer can be marked critical. The text for that extension = says: CRL issuers MUST mark this extension as critical since an implementation that ignored this extension could not correctly attribute CRL entries to certificates. This specification RECOMMENDS that implementations recognize this extension. Your support of Denis' text means that you think that reasoning is = wrong, and that if an implementation ignored the RECOMMENDS in that last = sentence, the implementation then doesn't need to pay attention to the = CertificateIssuer at all. And, yes, I changed the Subject line. This is not an errata: it is a = proposed technical change. --Paul Hoffman= From hotz@jpl.nasa.gov Thu Aug 23 15:54:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDFD21F852C for ; Thu, 23 Aug 2012 15:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.66 X-Spam-Level: X-Spam-Status: No, score=-6.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laKX97SBpNsb for ; Thu, 23 Aug 2012 15:54:12 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7A521F8522 for ; Thu, 23 Aug 2012 15:54:12 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7NMs75H028455 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 23 Aug 2012 15:54:08 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Thu, 23 Aug 2012 15:54:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120822144231.CA38C1A1A7@ld9781.wdf.sap.corp> To: "" X-Mailer: Apple Mail (2.1084) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 22:54:12 -0000 I hope I can interpret this exchange as converging toward consensus that = clarification and consensus is needed. ;-) On Aug 22, 2012, at 9:57 AM, = wrote: > Martin,=20 >=20 > > > I answered too quickly to your last email. > > >=20 > > > The text you mentioned > > > ("The critical flag SHOULD NOT be set for any of them")=20 > > > is in section 4.1.2, i.e. Notes on the Request Syntax. > > >=20 > > > So it only applies to the request, not to the response. > > >=20 > > > There is no text in RFC 2560 which forbids (or even does not = recommend) > > > to use critical single extensions within a response. > >=20 > > It could be that I still do not understand what you're really > > trying to accomplish and how. > >=20 > > I do not have a problem with critical extensions (in both request = and > > response) in principle, I just wanted to point out that the = presence > > of (and dealing with) a an extension that is marked critical is > > not specified in rfc2560, which means that ANY behaviour is = conforming, > > although there is some likelyhood that the presence of an = unrecognized > > extension that is marked critical will result in the complete = response > > to be dropped/ignored.=20 >=20 > A singleExtensions that is critical and not recognized will result in = the single response to be dropped/ignored.=20 It seems to me that a critical extension in a response ought to cause = the response to be rejected. If that constitutes an incompatible = upgrade to the protocol, so be it, but it sounds more like a = clarification to me. I hope the installed base agrees with me. > > Therefore sending a critical extension in an OCSP request would = probably > > be a bad idea, because a server that does not recognize it may = return > > an error (and it would require a second request or out-of-band = meta-knowledge > > to know whether a server supports the extension). >=20 > I am not discussing such a case.=20 >=20 > > The OCSP server returning an OCSP resonse with a critical = singleResponse > > extension, which has *NOT* been offered in the OCSP request through > > a non-critical singleRequest extensions is a BAD idea. Nothing > > in rfc2560 descibed the exact semantics of critical = singleResponseExtensions, > > so for rfc2560 they're simply prohibited--that is an implicit = consistency > > requirement.=20 >=20 > This is one of the many topics on which RFC 2560 is obscure; hence why = we are working on 2560bis.=20 >=20 > > That an unrecognized critical singleResponse extension applies = should > > not cause the rejection of the whole response is not backed by any > > existing specifications. rfc2560 certainly does not specify it. > > So the behaviour is undefined. >=20 > This is one of the many topics on which RFC 2560 is obscure; hence why = we are working on 2560bis.=20 > =20 > > For those who believe that rfc5280 should provide fallback guidance, > > look at what semantics rfc5280 specifies for critical = crlEntryExtensions: > >=20 > > http://tools.ietf.org/html/rfc5280#section-5.3 > >=20 > > If a CRL > > contains a critical CRL entry extension that the application = cannot > > process, then the application MUST NOT use that CRL to determine = the > > status of any certificates. However, applications may ignore > > unrecognized non-critical CRL entry extensions. >=20 > > rfc5280 specifies that a single unrecognized critical = crlEntryExtension > > anywhere in the CRL should cause the RP to completely ignore/drop = the > > entire signed object (the complete CRL). >=20 > This is an interesting point which deserves a separate thread.=20 > I believe this is an error and that we should discuss it as an errata = to RFC 5280.=20 Within the context of OCSP the "object" to be dropped would be an entire = response, because it's only requested for a single cert? I have a hard = time interpreting the meaning of any finer granularity than that. Or at = least a hard time finding a good use case for it. > > The semantics that you are asking--the criticality of a > > singleResponseExtensions applies only to that particular = singleResponse > > and should be ignored with respect to all other information in the=20= > > signed object (the OCSP response) is not specified in rfc2560, > > and is the exact opposite of the sematics specified in a vaguely > > similar situation in section 5.3 of PKIX/rfc5280 for the criticality = of > > CRLEntryExtensions. >=20 > > I'm OK with extending OCSP to support such semantics, provided that > > these semantics are properly negotiated(!) between OCSP requestor = and OCSP > > responder, which means that the OCSP request MUST contain a request > > extension indicating support for these semantics. >=20 > I now understand your point, but I do not think that the reject of a = whole response is logical=20 > if there is a critical unrecognized extension within a single = response.=20 >=20 > > However, since there are scenarios where OCSP responses are = forwarded > > _without_ an original OCSP request from the client that is supposed > > to process them (e.g. in the TLS extensions for OCSP response = stapling), > > use of critical OCSP response extensions ought to be limited to > > very exceptional situations that will not occur in regular usage > > scenarios where e.g. OCSP response stapling is desirable. >=20 > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From piyush@identicate.com Thu Aug 23 17:02:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C6C21F860F for ; Thu, 23 Aug 2012 17:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+4ZogY9NmKg for ; Thu, 23 Aug 2012 17:02:37 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id A529B21F860E for ; Thu, 23 Aug 2012 17:02:31 -0700 (PDT) Received: from mail95-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 Aug 2012 00:02:30 +0000 Received: from mail95-co1 (localhost [127.0.0.1]) by mail95-co1-R.bigfish.com (Postfix) with ESMTP id 488887400F2; Fri, 24 Aug 2012 00:02:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.229; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0610HT003.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: PS-28(zz9371Ic85fh1444Mfb6I1432Izz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail95-co1: domain of identicate.com designates 157.56.244.229 as permitted sender) client-ip=157.56.244.229; envelope-from=piyush@identicate.com; helo=CH1PRD0610HT003.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail95-co1 (localhost.localdomain [127.0.0.1]) by mail95-co1 (MessageSwitch) id 134576653534353_29381; Fri, 24 Aug 2012 00:02:15 +0000 (UTC) Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.225]) by mail95-co1.bigfish.com (Postfix) with ESMTP id EE682240047; Fri, 24 Aug 2012 00:02:14 +0000 (UTC) Received: from CH1PRD0610HT003.namprd06.prod.outlook.com (157.56.244.229) by CO1EHSMHS030.bigfish.com (10.243.66.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Aug 2012 00:02:12 +0000 Received: from CH1PRD0610MB393.namprd06.prod.outlook.com ([169.254.11.45]) by CH1PRD0610HT003.namprd06.prod.outlook.com ([10.255.151.38]) with mapi id 14.16.0175.005; Fri, 24 Aug 2012 00:02:06 +0000 From: Piyush Jain To: "denis.pinkas@bull.net" , "mrex@sap.com" , "pkix@ietf.org" Thread-Topic: [pkix] Errata in section 5.3 from RFC 5280 Thread-Index: AQHNgIeJt+ZtG1v2/0SUVkmWWswva5dmTUaAgAFaMgCAAGo68A== Date: Fri, 24 Aug 2012 00:02:05 +0000 Message-ID: References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.25.128.241] Content-Type: multipart/alternative; boundary="_000_AA6BA445CBFDB84785CC1C45DAAE4C79137BCBE0CH1PRD0610MB393_" MIME-Version: 1.0 X-OriginatorOrg: identicate.com Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 00:02:39 -0000 --_000_AA6BA445CBFDB84785CC1C45DAAE4C79137BCBE0CH1PRD0610MB393_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Note 5 seems out of context. Therefore, a critical extension in the crlEntryExtensions field of an entry shall affect only the certificate specified in that entry, unle= ss there is a related critical extension in the crlExtensions field that advertises a special treatment for it. The only ex= ample of this situation defined in this Directory Specification is the certificateIssuer CRL entry extension and th= e related issuingDistributionPoint CRL extension when the indirectCRL Boolean from that extension is set to TRUE. Note 4 specifies minimum action but does not impose any constraints on maxi= mum. Based on above text from X.509 existing text in 5280 seems incorrect (impo= sing restrictions unconditionally). However your proposed text would lead to incorrect behavior if a CRL extens= ion dictates that a CRL entry extension affects more than just the entry in= which it is present, a valid scenario according to X.509 -Piyush From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of den= is.pinkas@bull.net Sent: Thursday, August 23, 2012 10:25 AM To: mrex@sap.com; pkix@ietf.org Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 Martin, Your email is quite interesting and I was not thinking that the discussion = on OCSP would lead to look at CRLs as defined in X.509. Let me first say that RFC 2459 <--> RFC 5280 are supposed to be a *profile= * of X.509, which means dropping some of its complexity, but not changing its semantics= . RFC 2459 <--> RFC 5280 are clearly changing the semantics of the processin= g of crlEntryExtensions. Remainder: do not confuse crlEntryExtensions with crlExtensions. Let me put together the two paragraphs extracted from X.509 by Martin: NOTE 5 -- (...) An extension indicated in the crlEntryExtensions field of an entry= shall be placed in that entry and shall affect only the certificate(s) specified in that entry. NOTE 4 -- When an implementation processing a certificate revocation list does not recognize a critical extension in the crlEntryExtens= ions field, it shall assume that, at a minimum, the identified certific= ate has been revoked and is no longer valid and perform additional act= ions concerning that revoked certificate as dictated by local policy. This validates my text proposal which still is: If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL entry to determine the status of this certificate". : The key question is : which text "makes sense" ? Using an example, let us see the implications using a CRL with 5000 entries= . Using the text from X.509, when you look for the revocation status of a cer= tificate in a CRL you look for the serial number of that certificate. If an entry contains that serial= number, then you look also at that crlEntryExtensions (you process it) and you are done with a result. Using the text from RFC 5280, when you look for the revocation status of a = certificate in a CRL, you need to look at each of the 5000 entries to see if there is a single crlEntryExt= ension that you don't understand and which is marked critical. If one exists, you can't= determine the revocation status of that certificate, even if there is no single critical crlEntryExtension = present in the entry which contains the serial number of that certificate. The text from X.509 makes sense, while the text from RFC 5280 does not. If we keep the current text from RFC 5280, then RFC 5280 is not compatible= with X.509. This is a serious issue. Many calls for tenders request "X.509 compatibility" and also request RFC 5= 280 compatibility for convenience. How would it be possible to refer to two documents that are incompatible ? Denis > > > > "If a CRL contains a critical CRL entry extension that the applicatio= n > > cannot process, then the application MUST NOT use that CRL to > > determine the status of any certificates". > > > > This should be changed into: > > > > "If a CRL contains a critical CRL entry extension that the applicatio= n > > cannot process, then the application MUST NOT use that CRL entry to > > determine the status of this certificate". > > I'll note that your suggested replacement would create a security problem= . > > First of all, this semantic has been present in the spec since rfc2459. > Your suggested change would be backwards-incompatible and affect EVERY > PKI implementation that implements CRL processing. You simply > can not perform such a change to an installed base at this point in time. > > So I'm opposing your change. > > Curiously, ITU-T X.509 differs from PKIX (rfc2459->rfc5280) on the > semantics when encountering an unrecognized critical CrlEntryExtension: > (relevant parts prefixed with *>) > > As you may notice, X.509 does *NOT* specify, that the CRLEntry should > be ignored when accompanied by a critical CRLEntryExtension. It would > cause a security problem if it did. > > Quoting from ITU-T Tec. X.509 (08/2005), Section 7.3, top of page 18: > > *> NOTE 4 -- When an implementation processing a certificate revocation > *> list does not recognize a critical extension in the crlEntryExtension= s > *> field, it shall assume that, at a minimum, the identified certificate > *> has been revoked and is no longer valid and perform additional action= s > concerning that revoked certificate as dictated by local policy. > When an implementation does not recognize a critical extension in the > crlExtensions field, it shall assume that identified certificates > have been revoked and are no longer valid. However in the latter case= , > since the list may not be complete, certificates that have not been > identified as being revoked cannot be assumed to be valid. In this ca= se > local policy shall dictate the action to be taken. In any case local > policy may dictate actions in addition to and/or stronger than those > stated in this Specification. > > NOTE 5 -- If an extension affects the treatment of the list > (e.g., multiple CRLs need to be scanned to examine the entire list of > revoked certificates, or an entry may represent a range of certificat= es), > then that extension shall be indicated as critical in the crlExtensio= ns > field regardless of where the extension is placed in the CRL. > *> An extension indicated in the crlEntryExtensions field of an entry sh= all > *> be placed in that entry and shall affect only the certificate(s) > *> specified in that entry. > > > Although I find the original X.509 semantics for processing > CRLEntryExtensions much more reasonable than what rfc2459->rfc5280 says, > I firmly believe that as IETF we can not retroactively change the > semantics for processing critical CRLEntryExtensions for > rfc2459->rfc5280 & implementations based on these (proposed) standards > (in a backwards-incompatible fashion). > > > -Martin --_000_AA6BA445CBFDB84785CC1C45DAAE4C79137BCBE0CH1PRD0610MB393_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Note 5 seems out of conte= xt.

 <= /p>

Therefor= e, a critical extension in the crlEntryExtensions field

of an en= try shall affect only the certificate specified in that entry, unless there= is a related critical extension in the

crlExtens= ions field that advertises a special treatment for it. = The only example of this situation defined in this

Director= y Specification is the certificateIssuer CRL entry extension and the related issuingDistributionPoint CRL

extension when the indirectCRL Boolean from that extension is set to TRUE.

 <= /p>

Note 4 specifies minimum = action but does not impose any constraints on maximum.

 <= /p>

Based on above  text= from X.509 existing text in 5280 seems incorrect (imposing restrictions un= conditionally).

 <= /p>

However your proposed tex= t would lead to incorrect behavior if a CRL extension dictates that a CRL e= ntry extension affects more than just the entry in which it is present, a valid scenario according to X.509

 <= /p>

-Piyush=

 <= /p>

From: pkix-bou= nces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net
Sent: Thursday, August 23, 2012 10:25 AM
To: mrex@sap.com; pkix@ietf.org
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280

 

Martin,

Your email is quite interesting and I was not thinking that the = discussion on OCSP would lead
to look at CRLs as defined in  X.509.

Let me first say that RFC  2459 <--> RFC 5280 are sup= posed to be a *profile* of X.509,
which means dropping some of its complexity, but not changing its semantics= .

RFC  2459 <--> RFC 5280 are clearly changing the sema= ntics of the processing of crlEntryExtensions.=

Remainder: do not confuse crlEntryExte= nsions with crlExtensions.

Let me put together the two paragraphs= extracted from X.509 by Martin:

NOTE 5 -- (...)
         An extension indicated in the crlEntr= yExtensions field of an entry shall
         be placed in that entry and shall aff= ect only the certificate(s)
         specified in that entry. =

NOTE 4 -- When an implementation proce= ssing a certificate revocation
         list does not recognize a critical ex= tension in the crlEntryExtensions
         field, it shall assume that, at a min= imum, the identified certificate
         has been revoked and is no longer val= id and perform additional actions
         concerning that revoked certificate a= s dictated by local policy.

This validates my text proposal which still is:

   If a CRL contains a criti= cal CRL entry extension that the application
  cannot process, then the application MUST NOT use that CRL entry= to
  determine the status of this certificate". :

The key question is : which text "makes sense" ?

Using an example, let us see the implications using a CRL with 5= 000 entries.

Using the text from X.509, when you look for the revocation stat= us of a certificate in a CRL you look
for the serial number of that certificate. If an entry contains = that serial number,  then you look also
at that crlEntryExte= nsions (you process it) and you are done with a resu= lt.

Using the text from RFC 5280, when you look for the revocation s= tatus of a certificate in a CRL, you need
to look at each of the 5000 entries to see if there is a single crlEntryExtension that
you don't understand and which is marked critical. If one exists= , you can't determine the revocation status
of that certificate, even if there is no single critical crlEntryExtension  pr= esent in the entry which contains
the serial number of that certificate.

The text from X.509 makes sense, while the text from RFC 5280 do= es not.

 If we keep the current text from RFC 5280, then RFC 5280 i= s not compatible with X.509.

This is a serious issue.

Many calls for tenders request "X.509 compatibility" a= nd also request RFC 5280 compatibility for convenience.
How would it be possible to refer to two documents that are inco= mpatible ?

Denis  

> >
> >   "If a CRL contains a critical CRL entry extension= that the application
> >   cannot process, then the application MUST NOT use that= CRL to
> >   determine the status of any certificates". <= br> > >
> > This should be changed into:
> >
> >   "If a CRL contains a critical CRL entry extension= that the application
> >   cannot process, then the application MUST NOT use that= CRL entry to
> >   determine the status of this certificate". <= br> >
> I'll note that your suggested replacement would create a security = problem.
>
> First of all, this semantic has been present in the spec since rfc= 2459.
> Your suggested change would be backwards-incompatible and affect E= VERY
> PKI implementation that implements CRL processing.  You simpl= y
> can not perform such a change to an installed base at this point i= n time.
>
> So I'm opposing your change.
>
> Curiously, ITU-T X.509 differs from PKIX (rfc2459->rfc5280) on = the
> semantics when encountering an unrecognized critical CrlEntryExten= sion:
> (relevant parts prefixed with *>)
>
> As you may notice, X.509 does *NOT* specify, that the CRLEntry sho= uld
> be ignored when accompanied by a critical CRLEntryExtension.  = ;It would
> cause a security problem if it did.
>
> Quoting from ITU-T Tec. X.509 (08/2005), Section 7.3, top of page = 18:
>
> *>  NOTE 4 -- When an implementation processing a certific= ate revocation
> *>  list does not recognize a critical extension in the cr= lEntryExtensions
> *>  field, it shall assume that, at a minimum, the identif= ied certificate
> *>  has been revoked and is no longer valid and perform ad= ditional actions
>     concerning that revoked certificate as dictated by l= ocal policy.
>     When an implementation does not recognize a critical= extension in the
>     crlExtensions field, it shall assume that identified= certificates
>     have been revoked and are no longer valid. However i= n the latter case,
>     since the list may not be complete, certificates tha= t have not been
>     identified as being revoked cannot be assumed to be = valid. In this case
>     local policy shall dictate the action to be taken. I= n any case local
>     policy may dictate actions in addition to and/or str= onger than those
>     stated in this Specification.
>
>     NOTE 5 -- If an extension affects the treatment of t= he list
>     (e.g., multiple CRLs need to be scanned to examine t= he entire list of
>     revoked certificates, or an entry may represent a ra= nge of certificates),
>     then that extension shall be indicated as critical i= n the crlExtensions
>     field regardless of where the extension is placed in= the CRL.
> *>  An extension indicated in the crlEntryExtensions field= of an entry shall
> *>  be placed in that entry and shall affect only the cert= ificate(s)
> *>  specified in that entry.
>
>
> Although I find the original X.509 semantics for processing > CRLEntryExtensions much more reasonable than what rfc2459->rfc5= 280 says,
> I firmly believe that as IETF we can not retroactively change the<= /tt>
> semantics for processing critical CRLEntryExtensions for
> rfc2459->rfc5280 & implementations based on these (proposed= ) standards
> (in a backwards-incompatible fashion).
>
>
> -Martin

--_000_AA6BA445CBFDB84785CC1C45DAAE4C79137BCBE0CH1PRD0610MB393_-- From piyush@identicate.com Thu Aug 23 17:07:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234B721F8504 for ; Thu, 23 Aug 2012 17:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suZw2gTPQe4A for ; Thu, 23 Aug 2012 17:07:45 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6727021F8516 for ; Thu, 23 Aug 2012 17:07:45 -0700 (PDT) Received: from mail191-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 Aug 2012 00:07:44 +0000 Received: from mail191-va3 (localhost [127.0.0.1]) by mail191-va3-R.bigfish.com (Postfix) with ESMTP id C158C44011F; Fri, 24 Aug 2012 00:07:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.229; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0610HT004.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371I1431Jc85fhzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail191-va3: domain of identicate.com designates 157.56.244.229 as permitted sender) client-ip=157.56.244.229; envelope-from=piyush@identicate.com; helo=CH1PRD0610HT004.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail191-va3 (localhost.localdomain [127.0.0.1]) by mail191-va3 (MessageSwitch) id 1345766863139520_24979; Fri, 24 Aug 2012 00:07:43 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.241]) by mail191-va3.bigfish.com (Postfix) with ESMTP id 1E33134004D; Fri, 24 Aug 2012 00:07:43 +0000 (UTC) Received: from CH1PRD0610HT004.namprd06.prod.outlook.com (157.56.244.229) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Aug 2012 00:07:42 +0000 Received: from CH1PRD0610MB393.namprd06.prod.outlook.com ([169.254.11.45]) by CH1PRD0610HT004.namprd06.prod.outlook.com ([10.255.151.39]) with mapi id 14.16.0175.005; Fri, 24 Aug 2012 00:07:42 +0000 From: Piyush Jain To: Santosh Chokhani , Russ Housley , "denis.pinkas@bull.net" Thread-Topic: [pkix] Errata in section 5.3 from RFC 5280 Thread-Index: AQHNgIeJt+ZtG1v2/0SUVkmWWswva5dmTUaAgAFaMgCAACh7gIAAAxkAgABDfEA= Date: Fri, 24 Aug 2012 00:07:41 +0000 Message-ID: References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.25.128.241] Content-Type: multipart/alternative; boundary="_000_AA6BA445CBFDB84785CC1C45DAAE4C79137BCBF2CH1PRD0610MB393_" MIME-Version: 1.0 X-OriginatorOrg: identicate.com Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 00:07:47 -0000 --_000_AA6BA445CBFDB84785CC1C45DAAE4C79137BCBF2CH1PRD0610MB393_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1. And X.509 makes it clear that a CRL extension can be used to indicate if CR= L entry extension affects more than just the entry in which it is present. So Denis's proposal is applicable only in cases where such CRL extensions (= e.g idp with indirectCRl set to true) are not present. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of San= tosh Chokhani Sent: Thursday, August 23, 2012 1:01 PM To: Russ Housley; denis.pinkas@bull.net Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 Russ, The problem with Denis's proposal is that he wants to replace the text of n= ot using the CRL. I have cited a specific example in 5280 itself where an entry extension sco= pe goes beyond that of the entry. It potentially impacts subsequent entrie= s. Thus, Denis's proposal is unacceptable. If he just wanted to add the sente= nce as opposed to replace, it would be fine. In general, unless 5280 and X.509 stated that an entry extension cannot imp= act semantics of anything in the CRL other than the entry itself, what you = say is unacceptable and potentially insecure. From: pkix-bounces@ietf.org [mailto:pkix-boun= ces@ietf.org] On Behalf Of Russ Hous= ley Sent: Thursday, August 23, 2012 3:50 PM To: denis.pinkas@bull.net Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 I agree with the proposal that Denis makes. I support his proposed text. This validates my text proposal which still is: If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL entry to determine the status of this certificate". : Russ --_000_AA6BA445CBFDB84785CC1C45DAAE4C79137BCBF2CH1PRD0610MB393_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1.=

 <= /p>

And X.509 makes it clear = that a CRL extension can be used to indicate if CRL entry extension affects= more than just the entry in which it is present.

So Denis’s proposal= is applicable only in cases where such CRL extensions (e.g idp with indire= ctCRl set to true) are not present.

 <= /p>

From: pkix-bou= nces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Santosh Chokhani
Sent: Thursday, August 23, 2012 1:01 PM
To: Russ Housley; denis.pinkas@bull.net
Cc: IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280

 

Russ,

 

The problem with Denis’= ;s proposal is that he wants to replace the text of not using the CRL.=

 

I have cited a specific exam= ple in 5280 itself where an entry extension scope goes beyond that of the e= ntry.  It potentially impacts subsequent entries.

 

Thus, Denis’s proposal= is unacceptable.  If he just wanted to add the sentence as opposed to= replace, it would be fine.

 

In general, unless 5280 and = X.509 stated that an entry extension cannot impact semantics of anything in= the CRL other than the entry itself, what you say is unacceptable and potentially insecure.

 

 

 

I agree with the proposal that Denis makes.  I = support his proposed text.

 

This val= idates my text proposal which still is: 

   If a CRL contains = a critical CRL entry extension that the application 
  cannot process, then the application MUST NOT use that CRL entry= to
  determine the status of this certificate". : 

 

Russ

--_000_AA6BA445CBFDB84785CC1C45DAAE4C79137BCBF2CH1PRD0610MB393_-- From SChokhani@cygnacom.com Thu Aug 23 17:52:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B813F21F847B for ; Thu, 23 Aug 2012 17:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTKuqxHuhTfn for ; Thu, 23 Aug 2012 17:52:37 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 08B5321F84A7 for ; Thu, 23 Aug 2012 17:52:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,301,1344225600"; d="scan'208,217";a="5999781" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 23 Aug 2012 20:52:30 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 23 Aug 2012 20:52:30 -0400 From: Santosh Chokhani To: Russ Housley Date: Thu, 23 Aug 2012 20:52:28 -0400 Thread-Topic: [pkix] Errata in section 5.3 from RFC 5280 Thread-Index: Ac2BbAONwi3UnTVXSeWvPpy/6oL8jAAJZ2xQ Message-ID: References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF36299E30scygexch7cygnac_" MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 00:52:39 -0000 --_000_B83745DA469B7847811819C5005244AF36299E30scygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Russ, If we buy your argument for a minute, whether we change the text or not doe= s not matter based on your assertion below. To paraphrase what you say bel= ow, those who process IDP will process certificate issuer and those who do = not process IDP will reject the CRL because of critical CRL extension. Sin= ce it does not matter, status quo is the best course. As Piyush Jain has pointed out in this thread, if 5280 wants to use X.509 t= ext, we may be able come to some agreement.. My concern is not the extensions listed in 5280. X.509 V3 is extensible be= cause you can define additional extensions. The criticality processing/enf= orcement needs to be robust in light of potential new extensions. Thus, un= less some caveats are added to the scope of an entry extension, this change= is unsound. From: Russ Housley [mailto:housley@vigilsec.com] Sent: Thursday, August 23, 2012 4:15 PM To: Santosh Chokhani Cc: denis.pinkas@bull.net; IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 Santosh: RFC 5280 describes three CRL Entry Extensions, and all of them come from X.= 509: 5.3.1. Reason Code 5.3.2. Invalidity Date 5.3.3. Certificate Issuer The first two do not have the concern that you describe, and the third one = should only be present if the CRL includes the IssuingDistributionPoint CRL= extension, and that extension includes the indirectCRL set to TRUE. The I= ssuingDistributionPoint CRL extension must be critical. RFC 5280 says: The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. To my mind, the support for the critical IssuingDistributionPoint CRL exten= sion includes the proper support for the Certificate Issuer CRL entry exten= sion. Russ On Aug 23, 2012, at 4:01 PM, Santosh Chokhani wrote: Russ, The problem with Denis's proposal is that he wants to replace the text of n= ot using the CRL. I have cited a specific example in 5280 itself where an entry extension sco= pe goes beyond that of the entry. It potentially impacts subsequent entrie= s. Thus, Denis's proposal is unacceptable. If he just wanted to add the sente= nce as opposed to replace, it would be fine. In general, unless 5280 and X.509 stated that an entry extension cannot imp= act semantics of anything in the CRL other than the entry itself, what you = say is unacceptable and potentially insecure. From: pkix-bounces@ietf.org [mailto:pkix-boun= ces@ietf.org] On Behalf Of Russ Hous= ley Sent: Thursday, August 23, 2012 3:50 PM To: denis.pinkas@bull.net Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 I agree with the proposal that Denis makes. I support his proposed text. This validates my text proposal which still is: If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL entry to determine the status of this certificate". : Russ --_000_B83745DA469B7847811819C5005244AF36299E30scygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Russ,

 

If we buy your argument for a minute, whether we change t= he text or not does not matter based on your assertion below.  To para= phrase what you say below, those who process IDP will process certificate i= ssuer and those who do not process IDP will reject the CRL because of criti= cal CRL extension.  Since it does not matter, status quo is the best c= ourse.

 

As Piyush Jain has pointed out in this threa= d, if 5280 wants to use X.509 text, we may be able come to some agreement..=

 

=

My concern is not the extensions listed in 5280.&n= bsp; X.509 V3 is extensible because you can define additional extensions.&n= bsp; The criticality processing/enforcement needs to be robust in light of = potential new extensions.  Thus, unless some caveats are added to the = scope of an entry extension, this change is unsound.

<= p class=3DMsoNormal> 

From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Thursday, August 23, 2012 4:15 PM
To: Santosh Chokhani
Cc= : denis.pinkas@bull.net; IETF PKIX
Subject: Re: [pkix] Errata= in section 5.3 from RFC 5280

 

Santosh:

<= div>

 

 

RFC 5280 describes = three CRL Entry Extensions, and all of them come from X.509:

=

 

     &= nbsp;      5.3.1.  Reason Code

 &= nbsp;          5.3.2. &= nbsp;Invalidity Date

         =    5.3.3.  Certificate Issuer

 

The first two do not have the concern that you describe, and the third one= should only be present if the CRL includes the IssuingDistributionPoi= nt CRL extension, and that extension includes the indirectCRL set to TRUE. =  The IssuingDistributionPoint CRL extension must be critical. &nb= sp;RFC 5280 says:

 =

   The issuing dis= tribution point is a critical CRL extension that

<= p class=3DMsoNormal>   identifies the CRL distribution point and = scope for a particular CRL,

&= nbsp;  and it indicates whether the CRL covers revocation for end enti= ty

   certificates = only, CA certificates only, attribute certificates only,

   or a limited set of reason codes. =  Although the extension is

   critical, conforming implementations are not required to su= pport this

   exten= sion.  However, implementations that do not support this

   extension MUST either treat t= he status of any certificate not listed

   on this CRL as unknown or locate another CRL that= does not contain

  &nbs= p;any unrecognized critical extensions.

 

To my= mind, the support for the critical IssuingDistributionPoint CRL extension = includes the proper support for the Certificate Issuer CRL entry = extension.

 <= /p>

Russ

 

&nbs= p;

On Aug 23, 2012, at 4:01 PM, Sa= ntosh Chokhani wrote:


Russ,<= /p>

 

The problem with Denis’s proposal is that= he wants to replace the text of not using the CRL.

 

I have cited a specific example in 5280 itself where= an entry extension scope goes beyond that of the entry.  It potential= ly impacts subsequent entries.

 

Thus, Denis’s proposal is unacceptable.  If he just wanted to = add the sentence as opposed to replace, it would be fine.=

 

<= div>

In general, unless 5280 and X.509 stated that = an entry extension cannot impact semantics of anything in the CRL other tha= n the entry itself, what you say is unacceptable and potentially insecure.<= /span>

 =

From: = <= a href=3D"mailto:pkix-bounces@ietf.org">pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of&n= bsp;Russ Housley
Sent: Thursday, August 23, 2012 3:50 PM
To: denis.pinkas@bull.net
Cc: IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280

 

 

I agree with the proposal that Denis makes.  I s= upport his proposed text.

 

Th= is validates my text proposal which still is: 

   If a CRL contains a critical CRL entry extension that t= he application 
  cannot process, then the application MUST N= OT use that CRL entry to
  = determine the status of this certificate". : 

 

Russ

 

= --_000_B83745DA469B7847811819C5005244AF36299E30scygexch7cygnac_-- From mrex@sap.com Thu Aug 23 18:30:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3633F21F865C for ; Thu, 23 Aug 2012 18:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.86 X-Spam-Level: X-Spam-Status: No, score=-9.86 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+6bglQvcHUV for ; Thu, 23 Aug 2012 18:30:07 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 562EF21F8658 for ; Thu, 23 Aug 2012 18:30:06 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q7O1U4K0016917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Aug 2012 03:30:05 +0200 (MEST) In-Reply-To: To: denis.pinkas@bull.net Date: Fri, 24 Aug 2012 03:30:04 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120824013004.19BD81A1AB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 01:30:08 -0000 Denis, I believe that the semantics of OCSP responses with unrecognized critical extensions are effectively undefined in rfc2560 so that their use ought to be avoided. I believe that for the purpose of conveying information about cert existence/non-existence in an OCSP response, non-critical (entry)extensions will be perfectly sufficient. It may be easier to discuss the issues by drilling down into the details. What needs to be accounted for is (a) what answer is best suited for the OCSP requestor, and (b) can the OCSP response confuse other RPs who obtain that response from caching, stapling, proxying, or from a malicious attacker? Traditional OCSP: rfc2560 response: issuer+serial refer to (1) real cert that is valid good (2) real cert that is revoked revoked (3) non-existent cert good Having the OCSP responder add the certificate hash of the REAL cert into a non-critical singleResponse extension for (1) and (2) should be safe according to rfc2560, _independent_ of which RP is going to process the repsonse. The whitelisting check that were discussing (comparing the hash of the cert that an RP is checking for revocation against the records of issued certs applies in theory to all three scenarios above. However, we ought to leave the ocsp responses semantics of (1) and (2) alone, and only modify the response (3). It would be dangerous to have an OCSP responder create a response with an rfc2560 CertID refering to a valid, unrevoked issued cert, accompanied by an incorrect cert hash in a singleResponse extensions and a revoked status, because the installed base does not understand the semantics of such a beast and it has a potential to be misunderstood. For (1) and (2), I (finally) agree with you Denis, for rfc2560 CertIDs refering to real issued certs, the OCSP response ought to convey the true status (good/revoked) and a whitelist-enabled OCSP responser should include the true hash of the issued cert in a non-critical OCSP singleResponseExtension, and the RP must be burdened with comparing the hash of the real cert with the hash of the cert the RP is verifying. What about situation (3). I do not see a problem with an OCSP responder who has access to a white list or issue records to return "revoked (on hold)" to discourage the RP from trusting this cert. But the validity of such a "denial-of-existance" OCSP response should be extremely short (to minimize interference with real certs that get issued shortly after such an OCSP response is created) similar how negative DNS responses ought to be short-lived. And such a "negative" OCSP response ought NOT to contain any cert hash in a singleResponse extension--the presence of a cert hash in the response should be limited to correct hashes of isssued certs. It's true that there is no need for the OCSP resquest to convey a cert hash to make the above happen. The purpose of a cert hash in the requst is really more about allowing an OCSP responder to detect when there are potentially fraudulently issued certs being used that the CA does not know about. I agree that it will be easy to create the impression of fraudulent cert usage by submitting OCSP requests for real certs accompanied by random hash values, so OCSP operators need to be careful about interpreting the collected data. But I do not see this as a problem. -Martin From mrex@sap.com Thu Aug 23 18:55:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6483A21F8645 for ; Thu, 23 Aug 2012 18:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.157 X-Spam-Level: X-Spam-Status: No, score=-10.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6dGe5FzeoOd for ; Thu, 23 Aug 2012 18:55:44 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7968621F8540 for ; Thu, 23 Aug 2012 18:55:44 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q7O1teJP012764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Aug 2012 03:55:40 +0200 (MEST) In-Reply-To: To: Santosh Chokhani Date: Fri, 24 Aug 2012 03:55:40 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120824015540.267301A1AB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 01:55:45 -0000 The real problem is this: A critical crlEntryExtension is IMHO semantical non-sense, saying: "A certificate is revoked, but only under the following constraints -- and if you don't understand this, consider the certificate valid". The guidance in X.509 is, that the criticality is to be ignored and the cert to which the CrlEntry refers must be considered revoked. And X.509 says that the creators of the non-sense ought to include a critical CRLExtension instead. this is what the beginning of Note 5 from X.509 08/2005 section 7.3, page 18 is about: NOTE 5 -- If an extension affects the treatment of the list (e.g., multiple CRLs need to be scanned to examine the entire list of revoked certificates, or an entry may represent a range of certificates), then that extension shall be indicated as critical in the crlExtensions field regardless of where the extension is placed in the CRL. rfc5280 "enforces" the latter guidance in its own fashion: a critical crlEntryExtension would have to accompanied by a critical crlExtension per X.509, and if it is unrecognized, then the whole CRL must be rejected as if this has been an unrecognized critical crlExtension (which per X.509 should have been there in the first place). For an implementation, however the rfc5280 description is much harder to implement. It is not unusal that the ASN.1 parser and the code that processes the objects (e.g. CRL checking) are seperate and independently maintaind. Potentially, the ASN.1 parser could even be compiler-generated, so that it could happen that a crlEntryExtension is not "unrecognized" for the ASN.1 Parser, but unrecognized for the code that performs CRL acutal checking. The rfc5280 definition implies, that in such a case the CRL checking code must scan the entire CRL (all entries) in order to ensure that there are no critical unrecognized crlEntryExtensions. -Martin From piyush@identicate.com Thu Aug 23 20:25:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF7C21E8034 for ; Thu, 23 Aug 2012 20:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi0gs0C+SouV for ; Thu, 23 Aug 2012 20:25:14 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id F33BB11E8091 for ; Thu, 23 Aug 2012 20:25:13 -0700 (PDT) Received: from mail65-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 Aug 2012 03:25:11 +0000 Received: from mail65-am1 (localhost [127.0.0.1]) by mail65-am1-R.bigfish.com (Postfix) with ESMTP id 628CB1C00A0; Fri, 24 Aug 2012 03:25:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.229; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0610HT004.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: PS-28(zz9371I542M1432I1418Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah1155h) Received-SPF: pass (mail65-am1: domain of identicate.com designates 157.56.244.229 as permitted sender) client-ip=157.56.244.229; envelope-from=piyush@identicate.com; helo=CH1PRD0610HT004.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail65-am1 (localhost.localdomain [127.0.0.1]) by mail65-am1 (MessageSwitch) id 1345778709317266_32140; Fri, 24 Aug 2012 03:25:09 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.245]) by mail65-am1.bigfish.com (Postfix) with ESMTP id 41C7B100232; Fri, 24 Aug 2012 03:25:09 +0000 (UTC) Received: from CH1PRD0610HT004.namprd06.prod.outlook.com (157.56.244.229) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Aug 2012 03:25:08 +0000 Received: from CH1PRD0610MB393.namprd06.prod.outlook.com ([169.254.11.45]) by CH1PRD0610HT004.namprd06.prod.outlook.com ([10.255.151.39]) with mapi id 14.16.0175.005; Fri, 24 Aug 2012 03:24:56 +0000 From: Piyush Jain To: "mrex@sap.com" , Santosh Chokhani Thread-Topic: [pkix] Errata in section 5.3 from RFC 5280 Thread-Index: AQHNgIeJt+ZtG1v2/0SUVkmWWswva5dmTUaAgAFaMgCAACh7gIAAAxkAgAAD5ACAAE14AIAAEagAgAARiuA= Date: Fri, 24 Aug 2012 03:24:56 +0000 Message-ID: References: <20120824015540.267301A1AB@ld9781.wdf.sap.corp> In-Reply-To: <20120824015540.267301A1AB@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.25.128.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: identicate.com Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 03:25:15 -0000 Please see inline. > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Martin Rex > Sent: Thursday, August 23, 2012 6:56 PM > To: Santosh Chokhani > Cc: IETF PKIX > Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 >=20 > The real problem is this: >=20 > A critical crlEntryExtension is IMHO semantical non-sense, saying: >=20 > "A certificate is revoked, but only under the following constraints -- a= nd if > you don't understand this, consider the certificate valid". >=20 Not sure if I understand the basis for this interpretation. Did you type "= valid" instead of "unknown" accidentally? > The guidance in X.509 is, that the criticality is to be ignored and the c= ert to > which the CrlEntry refers must be considered revoked. Only in some situations. > And X.509 says that the creators of the non-sense ought to include a crit= ical > CRLExtension instead. =20 Indirect CRLs are defined in X.509. So I doubt that the authors of X.509 co= nsidered it nonsense. In hindsight, based on adoption of indirect CRLs, you= can probably say that indirectCRLs are not useful but "nonsense" is little= strong. this is what the beginning of Note 5 from X.509 > 08/2005 section 7.3, page 18 is about: >=20 > NOTE 5 -- If an extension affects the treatment of the list > (e.g., multiple CRLs need to be scanned to examine the entire list of > revoked certificates, or an entry may represent a range of certificat= es), > then that extension shall be indicated as critical in the crlExtensio= ns > field regardless of where the extension is placed in the CRL. >=20 >=20 > rfc5280 "enforces" the latter guidance in its own fashion: a critical > crlEntryExtension would have to accompanied by a critical crlExtension pe= r > X.509, and if it is unrecognized, then the whole CRL must be rejected as = if this > has been an unrecognized critical crlExtension (which per > X.509 should have been there in the first place). >=20 Agreed. I think that carrying over X.509 text to 5280 is the right approach= to address this. >=20 > For an implementation, however the rfc5280 description is much harder to > implement. It is not unusal that the ASN.1 parser and the code that > processes the objects (e.g. CRL checking) are seperate and independently > maintaind. Potentially, the ASN.1 parser could even be compiler-generate= d, > so that it could happen that a crlEntryExtension is not "unrecognized" fo= r the > ASN.1 Parser, but unrecognized for the code that performs CRL acutal > checking. >=20 > The rfc5280 definition implies, that in such a case the CRL checking code= must > scan the entire CRL (all entries) in order to ensure that there are no cr= itical > unrecognized crlEntryExtensions. >=20 Agreed. The text needs to be changed. >=20 > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From ajs@anvilwalrusden.com Fri Aug 24 05:42:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC7F21F8501 for ; Fri, 24 Aug 2012 05:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1t5gXU1Rguu for ; Fri, 24 Aug 2012 05:42:53 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6172F21F8503 for ; Fri, 24 Aug 2012 05:42:53 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 9EBD08A031 for ; Fri, 24 Aug 2012 12:42:51 +0000 (UTC) Date: Fri, 24 Aug 2012 08:42:48 -0400 From: Andrew Sullivan To: pkix@ietf.org Message-ID: <20120824124248.GA60243@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [pkix] Update to CAA spec X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 12:42:53 -0000 On Thu, Aug 23, 2012 at 05:12:35PM -0400, Phillip Hallam-Baker wrote: > One issue that might be argued over is which order a CA should follow > aliases and search up the chain. As the draft stands is says, follow > the alias first and if that is empty then look in the domain above. I > suspect that it makes no difference which is done provided everyone > does the same thing. I haven't read the draft yet (I will), but in this matter, if that's what the draft says it is certainly the only correct thing to say. As a straightforward DNS matter, the alias _will_ be chased first. So it wouldn't be possible to climb the tree first, because when you run into a CNAME (or a DNAME at the parent), you start substitution. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From prvs=058393348c=rybar@nbusr.sk Fri Aug 24 06:38:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D4721F8683 for ; Fri, 24 Aug 2012 06:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.05 X-Spam-Level: X-Spam-Status: No, score=-0.05 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKfLd52yLpDT for ; Fri, 24 Aug 2012 06:38:48 -0700 (PDT) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id AB15A21F8592 for ; Fri, 24 Aug 2012 06:38:47 -0700 (PDT) Message-Id: <201208241338.q7O8vn1T087031@mail.nbusr.sk> From: "Peter Rybar" To: mrex@sap.com, denis.pinkas@bull.net Date: Fri, 24 Aug 2012 10:57:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Ac2BmAYKxbXKStHHRcqdc6AY6SOIEQAPm/4w In-Reply-To: <20120824013004.19BD81A1AB@ld9781.wdf.sap.corp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: *** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 3.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4319> : streams <804933> : uri <1200870> Cc: peterryb@gmail.com, 'pkix' Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 13:38:48 -0000 Martin, > But the validity of such a "denial-of-existance" OCSP response should be extremely short (to minimize interference with real certs that get issued shortly after such an OCSP response is created) similar how negative DNS responses... It looks like that thisUpdate time value is in online usage of OCPS = response ignored. Because thisUpdate time value indicates that = situations which happened after thisUpdate time was not covered in OCSP = response status. Online systems are based on probability where when something was true = recently it is expected that it is true also now when the online service = is used and for that reason thisUpdate of OCSP response is ignored. For = that reason OCSP response containing hash of certificate must be = processed together with the value included in thisUpdate to prevent it = from situations which you have described. For the long term validation thisUpdate time value of OCSP response (or = CRL) must be always before the time in the past to which the validation = is realized e.g. signature validation or other investigation of X.509 = PKI usage in the past. Peter -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Martin Rex Sent: Friday, August 24, 2012 3:30 AM To: denis.pinkas@bull.net Cc: pkix Subject: Re: [pkix] Use of the OSCP unknown response Denis, I believe that the semantics of OCSP responses with unrecognized = critical extensions are effectively undefined in rfc2560 so that their use ought to be avoided. I believe that for the purpose of conveying information about cert existence/non-existence in an OCSP response, non-critical (entry)extensions will be perfectly sufficient. It may be easier to discuss the issues by drilling down into the details. What needs to be accounted for is (a) what answer is best suited for the OCSP requestor, and (b) can the OCSP response confuse other RPs who obtain that response from caching, stapling, proxying, or from a malicious attacker? Traditional OCSP: rfc2560 response: issuer+serial refer to=20 (1) real cert that is valid good (2) real cert that is revoked revoked (3) non-existent cert good Having the OCSP responder add the certificate hash of the REAL cert into a non-critical singleResponse extension for (1) and (2) should be safe according to rfc2560, _independent_ of which RP is going to process the repsonse. The whitelisting check that were discussing (comparing the hash of the cert that an RP is checking for revocation against the records of issued certs applies in theory to all three scenarios above. However, we ought to leave the ocsp responses semantics of (1) and (2) alone, and only modify the response (3). It would be dangerous to have an OCSP responder create a response with an rfc2560 CertID refering to a valid, unrevoked issued cert, accompanied by an incorrect cert hash in a singleResponse extensions and a revoked status, because the installed base does not understand the semantics of such a beast and it has a potential to be misunderstood. For (1) and (2), I (finally) agree with you Denis, for rfc2560 CertIDs refering to real issued certs, the OCSP response ought to convey the true status (good/revoked) and a whitelist-enabled OCSP responser should include the true hash of the issued cert in a non-critical OCSP singleResponseExtension, and the RP must be burdened with comparing the hash of the real cert with the hash of the cert the RP is verifying.=20 What about situation (3). I do not see a problem with an OCSP responder who has access to a white list or issue records to return "revoked (on hold)" to discourage the RP from trusting this cert. But the validity of such a "denial-of-existance" OCSP response should be extremely short (to minimize interference with real certs that get issued shortly after such an OCSP response is created) similar how negative DNS responses ought to be short-lived. And such a "negative" OCSP response ought NOT to contain any cert hash in a singleResponse extension--the presence of a cert hash in the response should be limited to correct hashes of isssued certs. It's true that there is no need for the OCSP resquest to convey a cert hash to make the above happen. The purpose of a cert hash in the requst is really more about allowing an OCSP responder to detect when there are potentially fraudulently issued certs being used that the CA does not know about. I agree that it will be easy to create the impression of fraudulent cert usage by submitting OCSP requests for real certs accompanied by random hash values, so OCSP operators need to be careful about interpreting the collected data. But I do not see this as a problem. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From eabalea@gmail.com Fri Aug 24 11:01:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E94121F86C2 for ; Fri, 24 Aug 2012 11:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uM-+wcXVaOtX for ; Fri, 24 Aug 2012 11:01:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA5821F856F for ; Fri, 24 Aug 2012 11:01:29 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2655898vbb.31 for ; Fri, 24 Aug 2012 11:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=S27TvURZrdhXflcJu+meaXXUAaXR5Fnnk4kRDQFFm8o=; b=eeqGcDg3+GU/Ayo5Yd43s9jKtCmxi+FIQZp49UAqSZSGNqKDLSorkY7rSqAg7jxFbF UCrqWjw7ANO6sVNR10oC4iUx/wuYZbZqnysb9Y68Spb0zyV924LWK0vKnNRW1w3p2E31 Ehn6JmYxCz7HUWi2QDKUJa2+BZh7LAldT0kYs8c/GuOfvENX+8CynIkCjmxAwZNMzjW1 k/uHYIRglkLLtmvQGysacpA7ZrH8v27i9fuKGLXXklT38e/7ZKcmqicLxrFi5KR3TZXQ 07ThTKyXWL/BZ9+Y7/1Rvf/tTlfR7n9Uw736WkYXjbEFb+vxLGz4OIlBUOfb6XPIckr5 DzRA== MIME-Version: 1.0 Received: by 10.52.99.234 with SMTP id et10mr4585377vdb.18.1345831288582; Fri, 24 Aug 2012 11:01:28 -0700 (PDT) Received: by 10.58.235.232 with HTTP; Fri, 24 Aug 2012 11:01:28 -0700 (PDT) In-Reply-To: References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> Date: Fri, 24 Aug 2012 20:01:28 +0200 Message-ID: From: Erwann Abalea To: denis.pinkas@bull.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 18:01:31 -0000 Bonsoir, 2012/8/23 : > Let me first say that RFC 2459 <--> RFC 5280 are supposed to be a *profi= le* > of X.509, > which means dropping some of its complexity, but not changing its semanti= cs. The semantics has already been changed regarding trust anchor and validatio= n. CRL Processing (6.3.3) step (f) is incompatible with =C2=A78.1.5 of X.509 on self-issued certificates, for example. Trust anchor renewal as processed by RFC5280 is a problem on current CSCA deployments. --=20 Erwann. From peterryb@gmail.com Fri Aug 24 06:19:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729B721F857A for ; Fri, 24 Aug 2012 06:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJsixX1hBuUx for ; Fri, 24 Aug 2012 06:19:34 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1094921F853B for ; Fri, 24 Aug 2012 06:19:33 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2311874vcb.31 for ; Fri, 24 Aug 2012 06:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Lyk+cv50D9Dc/XkVWnVDhVikaVaXNvovu58qjt2XMCY=; b=Ru49r4+PmIL8ATnqn607MSKp4wYRVpT++E6wi9870IFWQU1eyaUtXU1JJb5HsnKJNn w4xre4ejc+73gc7SZ/mP5GtcAjBb+Ga5HTF3GKHmGMfK4yEVGRHO8Po2xZRJLvJf+UpJ TxqpGKwAM0UbRMw5wlaUgOUFj9VQKlKXtcij3lmiRM8/TauR3WnSQ72kdLzRlP9EFmWf GDnf0hn3Wc0HiG/mX+ynoDb2U6YlHcKFN7Co5amSHBa3pZ97TQSFeGPmEyh69szt24/F JBwzDQEYdC7/PKn1UirKryDaFDvOBZyJRcdGvbW0cs18kKVA9nd1bjVhdc7IfanFoX/s kp7A== MIME-Version: 1.0 Received: by 10.221.0.78 with SMTP id nl14mr4485913vcb.21.1345814373213; Fri, 24 Aug 2012 06:19:33 -0700 (PDT) Received: by 10.58.198.69 with HTTP; Fri, 24 Aug 2012 06:19:33 -0700 (PDT) In-Reply-To: <201208240857.q7O8vnhX087030@gw.nbusr.sk> References: <20120824013004.19BD81A1AB@ld9781.wdf.sap.corp> <201208240857.q7O8vnhX087030@gw.nbusr.sk> Date: Fri, 24 Aug 2012 15:19:33 +0200 Message-ID: From: Peter Rybar To: mrex@sap.com, denis.pinkas@bull.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 24 Aug 2012 22:24:18 -0700 Cc: PKIX Subject: Re: [pkix] Use of the OSCP unknown response X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 13:19:35 -0000 Ups replace "always before the time in " with "always after the time in " Time-line: time in the past when something was done and is checked with certificate < thisUpdate of (OCSP response with cert-hash value) < now Peter 2012/8/24 Peter Rybar : > Martin, > >> But the validity of such a "denial-of-existance" > OCSP response should be extremely short (to minimize interference > with real certs that get issued shortly after such an OCSP response > is created) similar how negative DNS responses... > > It looks like that thisUpdate time value is in online usage of OCPS respo= nse ignored. Because thisUpdate time value indicates that situations which = happened after thisUpdate time was not covered in OCSP response status. > > Online systems are based on probability where when something was true rec= ently it is expected that it is true also now when the online service is us= ed and for that reason thisUpdate of OCSP response is ignored. For that rea= son OCSP response containing hash of certificate must be processed together= with the value included in thisUpdate to prevent it from situations which = you have described. > > For the long term validation thisUpdate time value of OCSP response (or C= RL) must be always before the time in the past to which the validation is r= ealized e.g. signature validation or other investigation of X.509 PKI usage= in the past. > > Peter > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of M= artin Rex > Sent: Friday, August 24, 2012 3:30 AM > To: denis.pinkas@bull.net > Cc: pkix > Subject: Re: [pkix] Use of the OSCP unknown response > > Denis, > > I believe that the semantics of OCSP responses with unrecognized critical > extensions are effectively undefined in rfc2560 so that their use ought > to be avoided. > > I believe that for the purpose of conveying information about cert > existence/non-existence in an OCSP response, non-critical > (entry)extensions will be perfectly sufficient. > > It may be easier to discuss the issues by drilling down into > the details. > > What needs to be accounted for is (a) what answer is best suited > for the OCSP requestor, and (b) can the OCSP response confuse > other RPs who obtain that response from caching, stapling, proxying, > or from a malicious attacker? > > > Traditional OCSP: > rfc2560 response: > issuer+serial refer to > (1) real cert that is valid good > (2) real cert that is revoked revoked > (3) non-existent cert good > > > Having the OCSP responder add the certificate hash of > the REAL cert into a non-critical singleResponse extension > for (1) and (2) should be safe according to rfc2560, _independent_ > of which RP is going to process the repsonse. > > The whitelisting check that were discussing (comparing the > hash of the cert that an RP is checking for revocation against > the records of issued certs applies in theory to all three > scenarios above. However, we ought to leave the ocsp responses > semantics of (1) and (2) alone, and only modify the response (3). > > It would be dangerous to have an OCSP responder create a > response with an rfc2560 CertID refering to a valid, > unrevoked issued cert, accompanied by an incorrect cert > hash in a singleResponse extensions and a revoked status, > because the installed base does not understand the semantics > of such a beast and it has a potential to be misunderstood. > > > For (1) and (2), I (finally) agree with you Denis, for > rfc2560 CertIDs refering to real issued certs, the OCSP response > ought to convey the true status (good/revoked) and a whitelist-enabled > OCSP responser should include the true hash of the issued cert in > a non-critical OCSP singleResponseExtension, and the RP must be > burdened with comparing the hash of the real cert with the hash > of the cert the RP is verifying. > > > What about situation (3). I do not see a problem with an OCSP > responder who has access to a white list or issue records to > return "revoked (on hold)" to discourage the RP from trusting > this cert. But the validity of such a "denial-of-existance" > OCSP response should be extremely short (to minimize interference > with real certs that get issued shortly after such an OCSP response > is created) similar how negative DNS responses ought to be short-lived. > And such a "negative" OCSP response ought NOT to contain any cert hash > in a singleResponse extension--the presence of a cert hash in the > response should be limited to correct hashes of isssued certs. > > > It's true that there is no need for the OCSP resquest to convey > a cert hash to make the above happen. The purpose of a cert hash > in the requst is really more about allowing an OCSP responder > to detect when there are potentially fraudulently issued certs > being used that the CA does not know about. I agree that it will be > easy to create the impression of fraudulent cert usage by submitting > OCSP requests for real certs accompanied by random hash values, > so OCSP operators need to be careful about interpreting the > collected data. But I do not see this as a problem. > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From denis.pinkas@bull.net Mon Aug 27 00:02:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECAC21F8446 for ; Mon, 27 Aug 2012 00:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.226 X-Spam-Level: X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_20=-0.74, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M9TsEpllT6o for ; Mon, 27 Aug 2012 00:02:44 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 358C821F843A for ; Mon, 27 Aug 2012 00:02:44 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 4257F18045 for ; Mon, 27 Aug 2012 09:02:43 +0200 (CEST) To: pkix@ietf.org MIME-Version: 1.0 X-KeepSent: 4E25807C:93478038-C1257A64:0034F150; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Mon, 27 Aug 2012 09:02:41 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 27/08/2012 09:02:43, Serialize complete at 27/08/2012 09:02:43 Content-Type: multipart/alternative; boundary="=_alternative 0026A77DC1257A67_=" Subject: [pkix] Clarifications in section 4.2 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 07:02:46 -0000 Message en plusieurs parties au format MIME --=_alternative 0026A77DC1257A67_= Content-Type: text/plain; charset="US-ASCII" The discussion about the crlEntryExtensions lead me to read again sections 4.1.2.9 and 4.2 from RFC 5280. Section 4.2 has originally been written only in the context of certificate extensions, whereas extensions are now used by many other RFCs (in particular RFC 2560, which import the Extensions syntax and hence its description). The current text needs to be "clarified". I have reshuffled the text to separate the definition of "extensions", used by RFCs (including RFC 5280 and RFC 2560) from the definition of "certificate extensions". Basically, the text which was specific to "certificate extensions" has been moved into section 4.2.1. Section 4.2 which is called "Certificates Extensions" has been renamed "Extensions". It is specific to extensions which are used by any RFC which wants to use the syntax and its meaning. All the relationships with "certificate extensions" have been removed in the new section 4.2. You will find here after the (1) new proposed text, (2) the current text, and (3) an extract from X.509. NEW PROPOSED TEXT: 4.1.2.9. Extensions This field MUST only appear if the version is 3 (Section 4.1.2.1). If present, this field is a SEQUENCE of one or more extensions. The format and content of the extensions field are defined in section 4.2. 4.2. Extensions The extensions field allows addition of new fields to a structure without modification to the ASN.1 definition. An extension field consists of an extension identifier, a criticality flag, and an encoding of a data value of an ASN.1 type associated with the identified extension. Each extension includes an OID and an ASN.1 structure. When an extension appears in a structure , the OID appears as the field extnID and the corresponding ASN.1 DER encoded structure is the value of the octet string extnValue. A SEQUENCE MUST NOT include more than one instance of a particular extension. For those extensions where ordering of individual extensions within the SEQUENCE is significant, the specification of those individual extensions shall include the rules for the significance of the order therein. An extension includes the boolean critical, with a default value of FALSE. The text for each extension specifies the acceptable values for the critical field for implementations conforming to this profile. A processing system MUST reject the content of the SEQUENCE where the extension appears if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MUST be processed if it is recognized and MAY be ignored if it is not recognized. Note that any extension that is flagged non-critical will cause inconsistent behaviour between processing systems that will process the extension and processing systems that do not recognize the extension and will ignore it. 4.2.1. Standard Extensions The following sections present recommended extensions used within Internet certificates and standard locations for information. Communities may elect to use additional extensions; however, caution ought to be exercised in adopting any critical extensions in certificates that might prevent use in a general context. The extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys and for managing relationships between CAs. The X.509 v3 certificate format also allows communities to define private extensions to carry information unique to those communities. Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section 4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. If the CA issues certificates with an empty sequence for the subject field, the CA MUST support the subject alternative name extension (Section 4.2.1.6). Support for the remaining extensions is OPTIONAL. Conforming CAs MAY support extensions that are not identified within this specification; certificate issuers are cautioned that marking such extensions as critical may inhibit interoperability. At a minimum, applications conforming to this profile MUST recognize the following extensions: key usage (Section 4.2.1.3), certificate policies (Section 4.2.1.4), subject alternative name (Section 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended key usage (Section 4.2.1.12), and inhibit anyPolicy (Section 4.2.1.14). In addition, applications conforming to this profile SHOULD recognize the authority and subject key identifier (Sections 4.2.1.1 and 4.2.1.2) and policy mappings (Section 4.2.1.5) extensions. This section identifies standard certificate extensions defined in [X.509] for use in the Internet PKI. CURRENT TEXT: 4.1.2.9. Extensions This field MUST only appear if the version is 3 (Section 4.1.2.1). If present, this field is a SEQUENCE of one or more certificate extensions. The format and content of certificate extensions in the Internet PKI are defined in Section 4.2. 4.2. Certificate Extensions The extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys and for managing relationships between CAs. The X.509 v3 certificate format also allows communities to define private extensions to carry information unique to those communities. Each extension in a certificate is designated as either critical or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. The following sections present recommended extensions used within Internet certificates and standard locations for information. Communities may elect to use additional extensions; however, caution ought to be exercised in adopting any critical extensions in certificates that might prevent use in a general context. Each extension includes an OID and an ASN.1 structure. When an extension appears in a certificate, the OID appears as the field extnID and the corresponding ASN.1 DER encoded structure is the value of the octet string extnValue. A certificate MUST NOT include more than one instance of a particular extension. For example, a certificate may contain only one authority key identifier extension (Section 4.2.1.1). An extension includes the boolean critical, with a default value of FALSE. The text for each extension specifies the acceptable values for the critical field for CAs conforming to this profile. Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section 4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. If the CA issues certificates with an empty sequence for the subject field, the CA MUST support the subject alternative name extension (Section 4.2.1.6). Support for the remaining extensions is OPTIONAL. Conforming CAs MAY support extensions that are not identified within this specification; certificate issuers are cautioned that marking such extensions as critical may inhibit interoperability. At a minimum, applications conforming to this profile MUST recognize the following extensions: key usage (Section 4.2.1.3), certificate policies (Section 4.2.1.4), subject alternative name (Section 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended key usage (Section 4.2.1.12), and inhibit anyPolicy (Section 4.2.1.14). In addition, applications conforming to this profile SHOULD recognize the authority and subject key identifier (Sections 4.2.1.1 and 4.2.1.2) and policy mappings (Section 4.2.1.5) extensions. 4.2.1. Standard Extensions This section identifies standard certificate extensions defined in [X.509] for use in the Internet PKI. EXTRACT FROM X.509 page 14: The extensions field allows addition of new fields to the structure without modification to the ASN.1 definition. An extension field consists of an extension identifier, a criticality flag, and an encoding of a data value of an ASN.1 type associated with the identified extension. For those extensions where ordering of individual extensions within the SEQUENCE is significant, the specification of those individual extensions shall include the rules for the significance of the order therein. When an implementation processing a certificate does not recognize an extension, if the criticality flag is FALSE, it may ignore that extension. If the criticality flag is TRUE, unrecognized extensions shall cause the structure to be considered invalid, i.e., in a certificate, an unrecognized critical extension would cause validation of a signature using that certificate to fail. When a certificate-using implementation recognizes and is able to process an extension, then the certificate-using implementation shall process the extension regardless of the value of the criticality flag. Note that any extension that is flagged non-critical will cause inconsistent behaviour between certificate-using systems that will process the extension and certificate-using systems that do not recognize the extension and will ignore it. If unknown elements appear within the extension, and the extension is not marked critical, those unknown elements shall be ignored according to the rules of extensibility documented in 12.2.2 in ITU-T Rec. X.519 | ISO/IEC 9594-5. Denis --=_alternative 0026A77DC1257A67_= Content-Type: text/html; charset="US-ASCII" The discussion about the crlEntryExtensions lead me to read again sections 4.1.2.9
and 4.2 from RFC 5280.

Section 4.2 has originally been written only in the context of certificate extensions, whereas
extensions are now used by many other RFCs (in particular RFC 2560, which import the Extensions
syntax and hence its description).

The current text needs to be "clarified".

I have  reshuffled the text to separate the definition of "extensions", used by RFCs
(including RFC 5280 and RFC 2560) from the definition of  "certificate extensions".

Basically, the text which was specific to "certificate extensions" has been moved into section 4.2.1.

Section 4.2 which is called "Certificates Extensions" has been renamed  "Extensions".
It is specific to extensions which are used by any  RFC which wants to use the syntax and its meaning.
All the relationships with "certificate extensions" have been removed in the new section 4.2.

You will find here after the (1) new proposed text, (2) the current text, and (3) an extract from X.509.

NEW PROPOSED TEXT:

4.1.2.9.  Extensions
   This field MUST only appear if the version is 3 (Section 4.1.2.1).
   If present, this field is a SEQUENCE of one or more extensions.  
   The format and content of the extensions field are defined in
   section 4.2.

4.2.  Extensions

   The extensions field allows addition of new fields to a structure
   without modification to the ASN.1 definition.  An extension field
   consists of an extension identifier, a criticality flag, and an
   encoding of a data value of an ASN.1 type associated with the
   identified extension.

   Each extension includes an OID and an ASN.1 structure.  When an
   extension appears in a structure , the OID appears as the field
   extnID and the corresponding ASN.1 DER encoded structure is the
   value of the octet string extnValue.  A SEQUENCE MUST NOT include
   more than one instance of a particular extension.

   For those extensions where ordering of individual extensions within
   the SEQUENCE is significant, the specification of those individual
   extensions shall include the rules for the significance of the order
   therein.

   An extension includes the boolean critical, with a default value of
   FALSE.  The text for each extension specifies the acceptable values
   for the critical field for implementations conforming to this
   profile.

   A processing system MUST reject the content of the SEQUENCE where
   the extension appears if it encounters a critical extension it does
   not recognize or a critical extension that contains information that
   it cannot process.

   A non-critical extension MUST be processed if it is recognized and
   MAY be ignored if it is not recognized.

   Note that any extension that is flagged non-critical will cause
   inconsistent behaviour between processing systems that will process
   the extension and processing systems that do not recognize the
   extension and will ignore it.

   
4.2.1.  Standard Extensions

   The following sections present recommended extensions used within
   Internet certificates and standard locations for information.  

   Communities may elect to use additional extensions; however,
   caution ought to be exercised in adopting any critical extensions
   in certificates that might prevent use in a general context.

   The extensions defined for X.509 v3 certificates provide methods for
   associating additional attributes with users or public keys and for
   managing relationships between CAs.  The X.509 v3 certificate format
   also allows communities to define private extensions to carry
   information unique to those communities.  

   Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and
   4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section
   4.2.1.3), and certificate policies (Section 4.2.1.4) extensions.  If
   the CA issues certificates with an empty sequence for the subject  
   field, the CA MUST support the subject alternative name extension
   (Section 4.2.1.6).  Support for the remaining extensions is OPTIONAL.
   Conforming CAs MAY support extensions that are not identified within
   this specification; certificate issuers are cautioned that marking
   such extensions as critical may inhibit interoperability.

   At a minimum, applications conforming to this profile MUST recognize
   the following extensions: key usage (Section 4.2.1.3), certificate
   policies (Section 4.2.1.4), subject alternative name (Section
   4.2.1.6), basic constraints (Section 4.2.1.9), name constraints
   (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended
   key usage (Section 4.2.1.12), and inhibit anyPolicy (Section
   4.2.1.14).

   In addition, applications conforming to this profile SHOULD recognize
   the authority and subject key identifier (Sections 4.2.1.1 and
   4.2.1.2) and policy mappings (Section 4.2.1.5) extensions.

   This section identifies standard certificate extensions defined in
   [X.509] for use in the Internet PKI.

 CURRENT  TEXT:

4.1.2.9.  Extensions
   This field MUST only appear if the version is 3 (Section 4.1.2.1).
   If present, this field is a SEQUENCE of one or more certificate
   extensions.  The format and content of certificate extensions in the
   Internet PKI are defined in Section 4.2.

4.2.  Certificate Extensions

   The extensions defined for X.509 v3 certificates provide methods for
   associating additional attributes with users or public keys and for
   managing relationships between CAs.  The X.509 v3 certificate format
   also allows communities to define private extensions to carry
   information unique to those communities.  Each extension in a
   certificate is designated as either critical or non-critical.  A
   certificate-using system MUST reject the certificate if it encounters
   a critical extension it does not recognize or a critical extension
   that contains information that it cannot process.  A non-critical
   extension MAY be ignored if it is not recognized, but MUST be
   processed if it is recognized.  The following sections present
   recommended extensions used within Internet certificates and standard
   locations for information.  Communities may elect to use additional
   extensions; however, caution ought to be exercised in adopting any
   critical extensions in certificates that might prevent use in a
   general context.

   Each extension includes an OID and an ASN.1 structure.  When an
   extension appears in a certificate, the OID appears as the field
   extnID and the corresponding ASN.1 DER encoded structure is the value
   of the octet string extnValue.  A certificate MUST NOT include more
   than one instance of a particular extension.  For example, a
   certificate may contain only one authority key identifier extension
   (Section 4.2.1.1).  An extension includes the boolean critical, with
   a default value of FALSE.  The text for each extension specifies the
   acceptable values for the critical field for CAs conforming to this
   profile.

   Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and
   4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section
   4.2.1.3), and certificate policies (Section 4.2.1.4) extensions.  If
   the CA issues certificates with an empty sequence for the subject
   field, the CA MUST support the subject alternative name extension
   (Section 4.2.1.6).  Support for the remaining extensions is OPTIONAL.
   Conforming CAs MAY support extensions that are not identified within
   this specification; certificate issuers are cautioned that marking
   such extensions as critical may inhibit interoperability.

   At a minimum, applications conforming to this profile MUST recognize
   the following extensions: key usage (Section 4.2.1.3), certificate
   policies (Section 4.2.1.4), subject alternative name (Section
   4.2.1.6), basic constraints (Section 4.2.1.9), name constraints
   (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended
   key usage (Section 4.2.1.12), and inhibit anyPolicy (Section
   4.2.1.14).

   In addition, applications conforming to this profile SHOULD recognize
   the authority and subject key identifier (Sections 4.2.1.1 and
   4.2.1.2) and policy mappings (Section 4.2.1.5) extensions.

4.2.1.  Standard Extensions

   This section identifies standard certificate extensions defined in
   [X.509] for use in the Internet PKI.  


EXTRACT FROM X.509 page 14:

The extensions field allows addition of new fields to the structure without modification to the ASN.1 definition.
An extension field consists of an extension identifier, a criticality flag, and an encoding of a data value of
an ASN.1 type associated with the identified extension.

For those extensions where ordering of individual extensions within the SEQUENCE is significant,
the specification of those individual extensions shall include the rules for the significance of the order therein.

When an implementation processing a certificate does not recognize an extension, if the criticality flag is FALSE,
it may ignore that extension. If the criticality flag is TRUE, unrecognized extensions shall cause the structure
to be considered invalid, i.e., in a certificate, an unrecognized critical extension would cause validation of
a signature using that certificate to fail.

When a certificate-using implementation recognizes and is able to process an extension, then the
certificate-using implementation shall process the extension regardless of the value of the criticality flag.

Note that any extension that is flagged non-critical will cause inconsistent behaviour between certificate-using
systems that will process the extension and certificate-using systems that do not recognize the extension and will ignore it.

If unknown elements appear within the extension, and the extension is not marked critical, those unknown elements
shall be ignored according to the rules of extensibility documented in 12.2.2 in ITU-T Rec. X.519 | ISO/IEC 9594-5.


Denis
  --=_alternative 0026A77DC1257A67_=-- From sharon.boeyen@entrust.com Mon Aug 27 09:39:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6C721F8557 for ; Mon, 27 Aug 2012 09:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnI1KXXmep20 for ; Mon, 27 Aug 2012 09:39:16 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id D128721F8534 for ; Mon, 27 Aug 2012 09:39:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,321,1344225600"; d="scan'208,217";a="1792852" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 27 Aug 2012 12:39:12 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Mon, 27 Aug 2012 12:39:12 -0400 From: Sharon Boeyen To: Russ Housley Thread-Topic: [pkix] Errata in section 5.3 from RFC 5280 Thread-Index: AQHNgWwH3CKKlFKDe0yhDO+TlkrrvJdt1YVg Date: Mon, 27 Aug 2012 16:39:10 +0000 Message-ID: <65DA4BEA501AFC409DF274CC71ED01A53A551F2B@SOTTEXCH10.corp.ad.entrust.com> References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.161.14] Content-Type: multipart/alternative; boundary="_000_65DA4BEA501AFC409DF274CC71ED01A53A551F2BSOTTEXCH10corpa_" MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 16:39:31 -0000 --_000_65DA4BEA501AFC409DF274CC71ED01A53A551F2BSOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Russ, I realize the RFC 5280 references the 2005 edition of X.509. However = the 2009 edition (freely available at http://www.x500standard.com/index.php= ?n=3DIg.LatestAvail ) revises this text again slightly and I think makes th= e intent even clearer. It states (as part of the main text and no longer a = note): If an extension affects the treatment of the list (e.g., multiple CRLs need= to be scanned to examine the entire list of revoked certificates, or an en= try may represent a range of certificates), then either that extension or a= related extension shall be indicated as critical in the crlExtensions fiel= d. Therefore, a critical extension in the crlEntryExtensions field of an en= try shall affect only the certificate specified in that entry, unless there= is a related critical extension in the crlExtensions field that advertises= a special treatment for it. The only example of this situation defined in = this Specification is the certificateIssuer CRL entry extension and the rel= ated issuingDistributionPoint CRL extension when the indirectCRL Boolean fr= om that extension is set to TRUE. This is clearly the case for certificateIssuer as you indicate below and as= you note below the only other 2 standard crl entry extensions are irreleva= nt as they can only ever be non-critical and affect only the single identif= ied revoked certificate. Any private extension that might be defined as a c= rlEntry extension would also have to follow that same rule to be compliant = with the base standard. I do believe the 2005 text was clear but offer this= 2009 as additional confirmation of the intent (I personally find this text= even clearer). Cheers, Sharon From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Thursday, August 23, 2012 4:15 PM To: Santosh Chokhani Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 Santosh: RFC 5280 describes three CRL Entry Extensions, and all of them come from X.= 509: 5.3.1. Reason Code 5.3.2. Invalidity Date 5.3.3. Certificate Issuer The first two do not have the concern that you describe, and the third one = should only be present if the CRL includes the IssuingDistributionPoint CRL= extension, and that extension includes the indirectCRL set to TRUE. The I= ssuingDistributionPoint CRL extension must be critical. RFC 5280 says: The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. To my mind, the support for the critical IssuingDistributionPoint CRL exten= sion includes the proper support for the Certificate Issuer CRL entry exten= sion. Russ On Aug 23, 2012, at 4:01 PM, Santosh Chokhani wrote: Russ, The problem with Denis's proposal is that he wants to replace the text of n= ot using the CRL. I have cited a specific example in 5280 itself where an entry extension sco= pe goes beyond that of the entry. It potentially impacts subsequent entrie= s. Thus, Denis's proposal is unacceptable. If he just wanted to add the sente= nce as opposed to replace, it would be fine. In general, unless 5280 and X.509 stated that an entry extension cannot imp= act semantics of anything in the CRL other than the entry itself, what you = say is unacceptable and potentially insecure. From: pkix-bounces@ietf.org [mailto:pkix-boun= ces@ietf.org] On Behalf Of Russ Hous= ley Sent: Thursday, August 23, 2012 3:50 PM To: denis.pinkas@bull.net Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 I agree with the proposal that Denis makes. I support his proposed text. This validates my text proposal which still is: If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL entry to determine the status of this certificate". : Russ --_000_65DA4BEA501AFC409DF274CC71ED01A53A551F2BSOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Russ, I realize the RFC 5= 280 references the 2005 edition of X.509. However the 2009 edition (freely = available at http:/= /www.x500standard.com/index.php?n=3DIg.LatestAvail ) revises this text = again slightly and I think makes the intent even clearer. It states (as par= t of the main text and no longer a note):

 <= /p>

If an extension affects= the treatment of the list (e.g., multiple CRLs need to be scanned to exami= ne the entire list of revoked certificates, or an entry may represent a ran= ge of certificates), then either that extension or a related extension shall be indicated as critical in the crlExtensions field. Therefore, a critical ex= tension in the crlEntryExtensions field of an entry shall affect = only the certificate specified in that entry, unless there is a related cri= tical extension in the crlExtensions<= span style=3D"color:red"> field that advertises a special treatment for it.= The only example of this situation defined in this Specification is the certificateIssuer = CRL entry extension and the related issuingDistributionPoint CRL extension when the indirectCRL Boolean from that extension is set to TRUE.

 <= /p>

 <= /p>

This is clearly the case = for certificateIssuer as you indicate below and as you note below the only = other 2 standard crl entry extensions are irrelevant as they can only ever be non-critical and affect only the single identified r= evoked certificate. Any private extension that might be defined as a crlEnt= ry extension would also have to follow that same rule to be compliant with = the base standard. I do believe the 2005 text was clear but offer this 2009 as additional confirmation of = the intent (I personally find this text even clearer).

 <= /p>

Cheers,=

Sharon<= /p>

 <= /p>

 <= /p>

From: pkix-bou= nces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Thursday, August 23, 2012 4:15 PM
To: Santosh Chokhani
Cc: IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280

 

Santosh:

 

 

RFC 5280 describes three CRL Entry Extensions, and a= ll of them come from X.509:

 

   &nb= sp;        5.3.1.  Reason Co= de

   &nb= sp;        5.3.2.  Invalidit= y Date

   &nb= sp;        5.3.3.  Certifica= te Issuer

 

The first two do not have the concern that you descr= ibe, and the third one should only be present if the CRL includes the = IssuingDistributionPoint CRL extension, and that extension includes the ind= irectCRL set to TRUE.  The IssuingDistributionPoint CRL extension must be critical.  RFC 5280 says:

 

   The issuing distribution point is a cri= tical CRL extension that

   identifies the CRL distribution point a= nd scope for a particular CRL,

   and it indicates whether the CRL covers= revocation for end entity

   certificates only, CA certificates only= , attribute certificates only,

   or a limited set of reason codes.  = ;Although the extension is

   critical, conforming implementations ar= e not required to support this

   extension.  However, implementatio= ns that do not support this

   extension MUST either treat the status = of any certificate not listed

   on this CRL as unknown or locate anothe= r CRL that does not contain

   any unrecognized critical extensions.

 

To my mind, the support for the critical IssuingDist= ributionPoint CRL extension includes the proper support for the Certif= icate Issuer CRL entry extension.

 

Russ

 

 

On Aug 23, 2012, at 4:01 PM, Santosh Chokhani wrote:=



Russ,

 

The problem with Denis’= ;s proposal is that he wants to replace the text of not using the CRL.

 

I have cited a specific exam= ple in 5280 itself where an entry extension scope goes beyond that of the e= ntry.  It potentially impacts subsequent entries.

 

Thus, Denis’s proposal= is unacceptable.  If he just wanted to add the sentence as opposed to= replace, it would be fine.

 

In general, unless 5280 and = X.509 stated that an entry extension cannot impact semantics of anything in= the CRL other than the entry itself, what you say is unacceptable and potentially insecure.

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org]=  On Behalf Of Russ Housl= ey
Sent: Thursday, Au= gust 23, 2012 3:50 PM
To: denis.pinkas@bull.net
Cc: IETF PKIX
Subject: Re: [pkix= ] Errata in section 5.3 from RFC 5280

 

 

I agree with the proposal that Denis makes.  I = support his proposed text.

 

This val= idates my text proposal which still is: 

   If a CRL contains = a critical CRL entry extension that the application 
  cannot process, then the= application MUST NOT use that CRL entry to
  determine the status of = this certificate". : <= /o:p>

 

Russ

 

--_000_65DA4BEA501AFC409DF274CC71ED01A53A551F2BSOTTEXCH10corpa_-- From housley@vigilsec.com Mon Aug 27 09:42:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F0A21F8554 for ; Mon, 27 Aug 2012 09:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ArwNxxaxxba for ; Mon, 27 Aug 2012 09:42:32 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF4621F853F for ; Mon, 27 Aug 2012 09:42:31 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id ED3F59A4009; Mon, 27 Aug 2012 12:42:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id olVDe+LGh2pv; Mon, 27 Aug 2012 12:42:15 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 73F719A4002; Mon, 27 Aug 2012 12:42:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-187-558841052 From: Russ Housley In-Reply-To: <65DA4BEA501AFC409DF274CC71ED01A53A551F2B@SOTTEXCH10.corp.ad.entrust.com> Date: Mon, 27 Aug 2012 12:42:24 -0400 Message-Id: <4918BCF9-2556-4E9F-9398-2222E62D7E14@vigilsec.com> References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> <65DA4BEA501AFC409DF274CC71ED01A53A551F2B@SOTTEXCH10.corp.ad.entrust.com> To: Sharon Boeyen X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 16:42:33 -0000 --Apple-Mail-187-558841052 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sharon: Thanks for digging up those words. They support the position that I = have stated. How do you believe the clarifications document should change to express = this point? Russ On Aug 27, 2012, at 12:39 PM, Sharon Boeyen wrote: > Russ, I realize the RFC 5280 references the 2005 edition of X.509. = However the 2009 edition (freely available = athttp://www.x500standard.com/index.php?n=3DIg.LatestAvail ) revises = this text again slightly and I think makes the intent even clearer. It = states (as part of the main text and no longer a note): > =20 > If an extension affects the treatment of the list (e.g., multiple CRLs = need to be scanned to examine the entire list of revoked certificates, = or an entry may represent a range of certificates), then either that = extension or a related extension shall be indicated as critical in the = crlExtensionsfield. Therefore, a critical extension in the = crlEntryExtensions field of an entry shall affect only the certificate = specified in that entry, unless there is a related critical extension in = the crlExtensions field that advertises a special treatment for it. The = only example of this situation defined in this Specification is the = certificateIssuer CRL entry extension and the related = issuingDistributionPoint CRL extension when theindirectCRL Boolean from = that extension is set to TRUE. > =20 > =20 > This is clearly the case for certificateIssuer as you indicate below = and as you note below the only other 2 standard crl entry extensions are = irrelevant as they can only ever be non-critical and affect only the = single identified revoked certificate. Any private extension that might = be defined as a crlEntry extension would also have to follow that same = rule to be compliant with the base standard. I do believe the 2005 text = was clear but offer this 2009 as additional confirmation of the intent = (I personally find this text even clearer). > =20 > Cheers, > Sharon > =20 > =20 > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Russ Housley > Sent: Thursday, August 23, 2012 4:15 PM > To: Santosh Chokhani > Cc: IETF PKIX > Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 > =20 > Santosh: > =20 > =20 > RFC 5280 describes three CRL Entry Extensions, and all of them come = from X.509: > =20 > 5.3.1. Reason Code > 5.3.2. Invalidity Date > 5.3.3. Certificate Issuer > =20 > The first two do not have the concern that you describe, and the third = one should only be present if the CRL includes the = IssuingDistributionPoint CRL extension, and that extension includes the = indirectCRL set to TRUE. The IssuingDistributionPoint CRL extension = must be critical. RFC 5280 says: > =20 > The issuing distribution point is a critical CRL extension that > identifies the CRL distribution point and scope for a particular = CRL, > and it indicates whether the CRL covers revocation for end entity > certificates only, CA certificates only, attribute certificates = only, > or a limited set of reason codes. Although the extension is > critical, conforming implementations are not required to support = this > extension. However, implementations that do not support this > extension MUST either treat the status of any certificate not = listed > on this CRL as unknown or locate another CRL that does not contain > any unrecognized critical extensions. > =20 > To my mind, the support for the critical IssuingDistributionPoint CRL = extension includes the proper support for the Certificate Issuer CRL = entry extension. > =20 > Russ > =20 > =20 > On Aug 23, 2012, at 4:01 PM, Santosh Chokhani wrote: >=20 >=20 > Russ, > =20 > The problem with Denis=92s proposal is that he wants to replace the = text of not using the CRL. > =20 > I have cited a specific example in 5280 itself where an entry = extension scope goes beyond that of the entry. It potentially impacts = subsequent entries. > =20 > Thus, Denis=92s proposal is unacceptable. If he just wanted to add = the sentence as opposed to replace, it would be fine. > =20 > In general, unless 5280 and X.509 stated that an entry extension = cannot impact semantics of anything in the CRL other than the entry = itself, what you say is unacceptable and potentially insecure. > =20 > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Russ Housley > Sent: Thursday, August 23, 2012 3:50 PM > To: denis.pinkas@bull.net > Cc: IETF PKIX > Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 > =20 > =20 > I agree with the proposal that Denis makes. I support his proposed = text. > =20 > This validates my text proposal which still is:=20 >=20 > If a CRL contains a critical CRL entry extension that the = application=20 > cannot process, then the application MUST NOT use that CRL entry to > determine the status of this certificate". :=20 > =20 > Russ > =20 --Apple-Mail-187-558841052 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Russ, = I realize the RFC 5280 references the 2005 edition of X.509. However the = 2009 edition (freely available at ) revises this text again = slightly and I think makes the intent even clearer. It states (as part = of the main text and no longer a note):
If an extension affects the treatment of the list (e.g., multiple = CRLs need to be scanned to examine the entire list of revoked = certificates, or an entry may represent a range of certificates), then = either that extension or a related extension shall be indicated as = critical in the field. = Therefore, a critical extension in the  field of an entry shall affect only the = certificate specified in that entry, unless there is a related critical = extension in the crlExtensions field that advertises a = special treatment for it. The only example of this situation defined in = this Specification is the  CRL entry extension = and the related  CRL extension = when theindirectCRL Boolean from that = extension is set to This = is clearly the case for certificateIssuer as you indicate below and as = you note below the only other 2 standard crl entry extensions are = irrelevant as they can only ever be non-critical and affect only the = single identified revoked certificate. Any private extension that might = be defined as a crlEntry extension would also have to follow that same = rule to be compliant with the base standard. I do believe the 2005 text = was clear but offer this 2009 as additional confirmation of the intent = (I personally find this text even clearer).
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org= ] On Behalf Of Russ = Housley
Sent: Thursday, August 23, 2012 = 4:15 PM
To: Santosh = Chokhani
Cc: IETF = PKIX
Subject: Re: [pkix] Errata in = section 5.3 from RFC 5280
 
RFC 5280 describes three = CRL Entry Extensions, and all of them come from = X.509:
        &= nbsp;   5.3.1.  Reason = Code
        &= nbsp;   5.3.2. =  Invalidity Date
        &= nbsp;   5.3.3. =  Certificate Issuer
 
The first two do not have the concern that you = describe, and the third one should only be present if the CRL includes = the IssuingDistributionPoint CRL extension, and that extension = includes the indirectCRL set to TRUE. =  The IssuingDistributionPoint CRL extension must be critical. =  RFC 5280 says:
   The issuing = distribution point is a critical CRL extension = that
   identifies = the CRL distribution point and scope for a particular = CRL,
   and it = indicates whether the CRL covers revocation for end = entity
   certificates = only, CA certificates only, attribute certificates = only,
   or a limited = set of reason codes.  Although the extension = is
   critical, = conforming implementations are not required to support = this
   extension. =  However, implementations that do not support = this
   extension = MUST either treat the status of any certificate not = listed
   on this CRL = as unknown or locate another CRL that does not = contain
   any = unrecognized critical extensions.
 
To my mind, the support for the critical = IssuingDistributionPoint CRL extension includes the proper support for = the Certificate Issuer CRL entry = extension.
On Aug 23, 2012, at 4:01 = PM, Santosh Chokhani wrote:


The problem with Denis=92s proposal is that he wants to = replace the text of not using the = CRL.
I have cited a specific example in 5280 itself where an = entry extension scope goes beyond that of the entry.  It = potentially impacts subsequent = entries.
 
Thus, Denis=92s proposal is = unacceptable.  If he just wanted to add the sentence as opposed to = replace, it would be fine.
In general, unless 5280 and X.509 stated that an entry = extension cannot impact semantics of anything in the CRL other than the = entry itself, what you say is unacceptable and potentially = insecure.
 
 [mailto:pkix-bounces@ietf.org] On Behalf Of Russ = Housley
Sent: Thursday, August 23, 2012 = 3:50 PM
To:  IETF = PKIX
Subject: Re: [pkix] Errata in = section 5.3 from RFC = 5280
 
 
I agree with the proposal that Denis makes.  I = support his proposed text.
 
This = validates my text proposal which still is:    If a CRL contains a critical = CRL entry extension that the application 

  determine the status of this = certificate". 
Russ
, "pkix@ietf.org" Thread-Topic: [pkix] Clarifications in section 4.2 from RFC 5280 Thread-Index: AQHNhCH+jEbfdTk9TUizoswFtWv5xpdt1bMg Date: Mon, 27 Aug 2012 16:44:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.25.128.241] Content-Type: multipart/alternative; boundary="_000_AA6BA445CBFDB84785CC1C45DAAE4C79263524CFCH1PRD0610MB393_" MIME-Version: 1.0 X-OriginatorOrg: identicate.com Subject: Re: [pkix] Clarifications in section 4.2 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 16:44:47 -0000 --_000_AA6BA445CBFDB84785CC1C45DAAE4C79263524CFCH1PRD0610MB393_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Denis, I think your proposal is based on the assumption that existing text in sect= ion 4.1.2.9 applies to "type" Extensions as opposed to "instance" of Extens= ions within structure TBSCertificates. This assumption may not be correct because in later sections 5280 re- defin= es what Extensions mean in context of a CRL and in context of CRL entry. Your proposal would certainly require changes in 5.1.2.7 and 5.2. Also, your proposed text for Extension imposes restrictions on how other sp= ecifications can use this structure. Please see inline for additional comm= ents From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of den= is.pinkas@bull.net Sent: Monday, August 27, 2012 12:03 AM To: pkix@ietf.org Subject: [pkix] Clarifications in section 4.2 from RFC 5280 The discussion about the crlEntryExtensions lead me to read again sections = 4.1.2.9 and 4.2 from RFC 5280. Section 4.2 has originally been written only in the context of certificate = extensions, whereas extensions are now used by many other RFCs (in particular RFC 2560, which i= mport the Extensions syntax and hence its description). [piyush] The description in 4.2 applies specifically to extensions in conte= xt of tbsCertificates. The current text needs to be "clarified". I have reshuffled the text to separate the definition of "extensions", use= d by RFCs (including RFC 5280 and RFC 2560) from the definition of "certificate exte= nsions". Basically, the text which was specific to "certificate extensions" has been= moved into section 4.2.1. Section 4.2 which is called "Certificates Extensions" has been renamed "Ex= tensions". It is specific to extensions which are used by any RFC which wants to use = the syntax and its meaning. All the relationships with "certificate extensions" have been removed in th= e new section 4.2. [piyush] exisiting 4.2 applies to certificate extension. It does not apply= to any other extensions (CRL, Crl Entry or extensions used in 2560, 5055 o= r any other ARFC). Even within 5280 there are separate sections to define w= hat "Extensions" means in context of CRLs and CRL entries. You will find here after the (1) new proposed text, (2) the current text, a= nd (3) an extract from X.509. NEW PROPOSED TEXT: 4.1.2.9. Extensions This field MUST only appear if the version is 3 (Section 4.1.2.1). If present, this field is a SEQUENCE of one or more extensions. The format and content of the extensions field are defined in section 4.2. 4.2. Extensions The extensions field allows addition of new fields to a structure without modification to the ASN.1 definition. An extension field consists of an extension identifier, a criticality flag, and an encoding of a data value of an ASN.1 type associated with the identified extension. Each extension includes an OID and an ASN.1 structure. When an extension appears in a structure , the OID appears as the field extnID and the corresponding ASN.1 DER encoded structure is the value of the octet string extnValue. A SEQUENCE MUST NOT include more than one instance of a particular extension. [piyush] There could be scenarios outside 5280 where more than one instance= of same extensions in a sequence are useful. For those extensions where ordering of individual extensions within the SEQUENCE is significant, the specification of those individual extensions shall include the rules for the significance of the order therein. An extension includes the boolean critical, with a default value of FALSE. The text for each extension specifies the acceptable values for the critical field for implementations conforming to this profile. A processing system MUST reject the content of the SEQUENCE where the extension appears if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. [piyush] which SEQUENCE ? immediate parent or the top level SEQUENCE? I thi= nk it depends on the extension that is being defined. A non-critical extension MUST be processed if it is recognized and MAY be ignored if it is not recognized. [piyush] It is relevant in context of 5280 but other specifications should = be free to define their own processing rules. Note that any extension that is flagged non-critical will cause inconsistent behaviour between processing systems that will process the extension and processing systems that do not recognize the extension and will ignore it. 4.2.1. Standard Extensions The following sections present recommended extensions used within Internet certificates and standard locations for information. Communities may elect to use additional extensions; however, caution ought to be exercised in adopting any critical extensions in certificates that might prevent use in a general context. The extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys and for managing relationships between CAs. The X.509 v3 certificate format also allows communities to define private extensions to carry information unique to those communities. Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section 4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. If the CA issues certificates with an empty sequence for the subject field, the CA MUST support the subject alternative name extension (Section 4.2.1.6). Support for the remaining extensions is OPTIONAL. Conforming CAs MAY support extensions that are not identified within this specification; certificate issuers are cautioned that marking such extensions as critical may inhibit interoperability. At a minimum, applications conforming to this profile MUST recognize the following extensions: key usage (Section 4.2.1.3), certificate policies (Section 4.2.1.4), subject alternative name (Section 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended key usage (Section 4.2.1.12), and inhibit anyPolicy (Section 4.2.1.14). In addition, applications conforming to this profile SHOULD recognize the authority and subject key identifier (Sections 4.2.1.1 and 4.2.1.2) and policy mappings (Section 4.2.1.5) extensions. This section identifies standard certificate extensions defined in [X.509] for use in the Internet PKI. CURRENT TEXT: 4.1.2.9. Extensions This field MUST only appear if the version is 3 (Section 4.1.2.1). If present, this field is a SEQUENCE of one or more certificate extensions. The format and content of certificate extensions in the Internet PKI are defined in Section 4.2. 4.2. Certificate Extensions The extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys and for managing relationships between CAs. The X.509 v3 certificate format also allows communities to define private extensions to carry information unique to those communities. Each extension in a certificate is designated as either critical or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. The following sections present recommended extensions used within Internet certificates and standard locations for information. Communities may elect to use additional extensions; however, caution ought to be exercised in adopting any critical extensions in certificates that might prevent use in a general context. Each extension includes an OID and an ASN.1 structure. When an extension appears in a certificate, the OID appears as the field extnID and the corresponding ASN.1 DER encoded structure is the value of the octet string extnValue. A certificate MUST NOT include more than one instance of a particular extension. For example, a certificate may contain only one authority key identifier extension (Section 4.2.1.1). An extension includes the boolean critical, with a default value of FALSE. The text for each extension specifies the acceptable values for the critical field for CAs conforming to this profile. Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section 4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. If the CA issues certificates with an empty sequence for the subject field, the CA MUST support the subject alternative name extension (Section 4.2.1.6). Support for the remaining extensions is OPTIONAL. Conforming CAs MAY support extensions that are not identified within this specification; certificate issuers are cautioned that marking such extensions as critical may inhibit interoperability. At a minimum, applications conforming to this profile MUST recognize the following extensions: key usage (Section 4.2.1.3), certificate policies (Section 4.2.1.4), subject alternative name (Section 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended key usage (Section 4.2.1.12), and inhibit anyPolicy (Section 4.2.1.14). In addition, applications conforming to this profile SHOULD recognize the authority and subject key identifier (Sections 4.2.1.1 and 4.2.1.2) and policy mappings (Section 4.2.1.5) extensions. 4.2.1. Standard Extensions This section identifies standard certificate extensions defined in [X.509] for use in the Internet PKI. EXTRACT FROM X.509 page 14: The extensions field allows addition of new fields to the structure without= modification to the ASN.1 definition. An extension field consists of an extension identifier, a criticality flag,= and an encoding of a data value of an ASN.1 type associated with the identified extension. For those extensions where ordering of individual extensions within the SEQ= UENCE is significant, the specification of those individual extensions shall include the rules fo= r the significance of the order therein. When an implementation processing a certificate does not recognize an exten= sion, if the criticality flag is FALSE, it may ignore that extension. If the criticality flag is TRUE, unrecognized= extensions shall cause the structure to be considered invalid, i.e., in a certificate, an unrecognized critical = extension would cause validation of a signature using that certificate to fail. When a certificate-using implementation recognizes and is able to process a= n extension, then the certificate-using implementation shall process the extension regardless of = the value of the criticality flag. Note that any extension that is flagged non-critical will cause inconsisten= t behaviour between certificate-using systems that will process the extension and certificate-using systems that = do not recognize the extension and will ignore it. If unknown elements appear within the extension, and the extension is not m= arked critical, those unknown elements shall be ignored according to the rules of extensibility documented in 12.2= .2 in ITU-T Rec. X.519 | ISO/IEC 9594-5. Denis --_000_AA6BA445CBFDB84785CC1C45DAAE4C79263524CFCH1PRD0610MB393_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Denis,<= /p>

 <= /p>

I think your proposal is = based on the assumption that existing text in section 4.1.2.9 applies to &#= 8220;type” Extensions as opposed to “instance” of Extensi= ons within structure TBSCertificates.

 <= /p>

This assumption may not b= e correct because in later sections 5280 re- defines what Extensions mean i= n context of a CRL and in context of CRL entry.

Your proposal would certa= inly require changes in 5.1.2.7 and 5.2.

 <= /p>

Also, your proposed text = for Extension imposes restrictions on how other specifications can use this= structure.  Please see inline for additional comments

From: pkix-bou= nces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net
Sent: Monday, August 27, 2012 12:03 AM
To: pkix@ietf.org
Subject: [pkix] Clarifications in section 4.2 from RFC 5280

 

The discussion about the crlEntryExtensio= ns lead me to read again sections 4.1.2.9
and 4.2 from RFC 5280.

Section 4.2 has originally been written only in the context of c= ertificate extensions, whereas
extensions are now used by many other RFCs (in particular RFC 2560, which i= mport the Extensions
syntax and hence its description).

[piyush] The description = in 4.2 applies specifically to extensions in context of tbsCertificates.


The current text needs to be "clarified".

I have  reshuffled the text to separate the definition of &= quot;extensions", used by RFCs
(including RFC 5280 and RFC 2560) from the definition of  "certif= icate extensions".

Basically, the text which was specific to "certificate exte= nsions" has been moved into section 4.2.1.

Section 4.2 which is called "Certificates Extensions" = has been renamed  "Extensions".
It is specific to extensions which are used by any  RFC whi= ch wants to use the syntax and its meaning.
All the relationships with "certificate extensions" ha= ve been removed in the new section 4.2.

[piyush] exisiting 4.2 ap= plies  to certificate extension. It does not apply to any other extens= ions (CRL, Crl Entry or extensions used in 2560, 5055 or any other ARFC). Even within 5280 there are separate sections to define what &= #8220;Extensions” means in context of CRLs and CRL entries.



You will find here after the (1) new proposed text, (2) the curr= ent text, and (3) an extract from X.509.

NEW PROPOSED TEXT:

4.1.2.= 9.  Extensions

 =  This field MUST only appear if the version is 3 (Section 4.1.2.1).
 =  If present, this field is a SEQUENCE of one or more extensions. &nbs= p;
 =  The format and content of the extensions field are defined in
 =  section 4.2.

4.2. &= nbsp;Extensions

 =  The extensions field allows addition of new fields to a structure
 =  without modification to the ASN.1 definition.  An extension fie= ld
 =  consists of an extension identifier, a criticality flag, and an
 =  encoding of a data value of an ASN.1 type associated with the
 =  identified extension.

 =  Each extension includes an OID and an ASN.1 structure.  When an=
 =  extension appears in a structure , the OID appears as the field
 =  extnID and the corresponding ASN.1 DER encoded structure is the
 =  value of the octet string extnValue.  A SEQUENCE MUST NOT inclu= de
 =  more than one instance of a particular extension.

[piyush] There could be s= cenarios outside 5280 where more than one instance of same extensions in a = sequence are useful.


 =  For those extensions where ordering of individual extensions within
 =  the SEQUENCE is significant, the specification of those individual
 =  extensions shall include the rules for the significance of the order
 =  therein.

 =  An extension includes the boolean critical, with a default value of
 =  FALSE.  The text for each extension specifies the acceptable va= lues
 =  for the critical field for implementations conforming to this
 =  profile.

 =  A processing system MUST reject the content of the SEQUENCE where
 =  the extension appears if it encounters a critical extension it does
 =  not recognize or a critical extension that contains information that
 =  it cannot process.

[piyush] which SEQUENCE ?= immediate parent or the top level SEQUENCE? I think it depends on the exte= nsion that is being defined.  



 =  A non-critical extension MUST be processed if it is recognized and
 =  MAY be ignored if it is not recognized.

[piyush] It is relevant i= n context of 5280 but other specifications should be free to define their o= wn processing rules.


 =  Note that any extension that is flagged non-critical will cause
 =  inconsistent behaviour between processing systems that will process
 =  the extension and processing systems that do not recognize the
 =  extension and will ignore it.

 =  
4.2.1.=  Standard Extensions

 =  The following sections present recommended extensions used within
 =  Internet certificates and standard locations for information.  =

 =  Communities may elect to use additional extensions; however,
 =  caution ought to be exercised in adopting any critical extensions
 =  in certificates that might prevent use in a general context.

 =  The extensions defined for X.509 v3 certificates provide methods for=
 =  associating additional attributes with users or public keys and for<= /span>
 =  managing relationships between CAs.  The X.509 v3 certificate f= ormat
 =  also allows communities to define private extensions to carry
 =  information unique to those communities.  

 =  Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and
 =  4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section
 =  4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. &nb= sp;If
 =  the CA issues certificates with an empty sequence for the subject &n= bsp;
 =  field, the CA MUST support the subject alternative name extension
 =  (Section 4.2.1.6).  Support for the remaining extensions is OPT= IONAL.
 =  Conforming CAs MAY support extensions that are not identified within=
 =  this specification; certificate issuers are cautioned that marking
 =  such extensions as critical may inhibit interoperability.

 =  At a minimum, applications conforming to this profile MUST recognize=
 =  the following extensions: key usage (Section 4.2.1.3), certificate
 =  policies (Section 4.2.1.4), subject alternative name (Section
 =  4.2.1.6), basic constraints (Section 4.2.1.9), name constraints
 =  (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended<= /span>
 =  key usage (Section 4.2.1.12), and inhibit anyPolicy (Section
 =  4.2.1.14).

 =  In addition, applications conforming to this profile SHOULD recogniz= e
 =  the authority and subject key identifier (Sections 4.2.1.1 and
 =  4.2.1.2) and policy mappings (Section 4.2.1.5) extensions.

 =  This section identifies standard certificate extensions defined in
 =  [X.509] for use in the Internet PKI.

 CURRENT  TEXT:

4.1.2.= 9.  Extensions
 =  This field MUST only appear if the version is 3 (Section 4.1.2.1).
 =  If present, this field is a SEQUENCE of one or more certificate
 =  extensions.  The format and content of certificate extensions i= n the
 =  Internet PKI are defined in Section 4.2.

4.2. &= nbsp;Certificate Extensions

 =  The extensions defined for X.509 v3 certificates provide methods for=
 =  associating additional attributes with users or public keys and for<= /span>
 =  managing relationships between CAs.  The X.509 v3 certificate f= ormat
 =  also allows communities to define private extensions to carry
 =  information unique to those communities.  Each extension in a
 =  certificate is designated as either critical or non-critical.  = A
 =  certificate-using system MUST reject the certificate if it encounter= s
 =  a critical extension it does not recognize or a critical extension
 =  that contains information that it cannot process.  A non-critic= al
 =  extension MAY be ignored if it is not recognized, but MUST be
 =  processed if it is recognized.  The following sections present<= /span>
 =  recommended extensions used within Internet certificates and standar= d
 =  locations for information.  Communities may elect to use additi= onal
 =  extensions; however, caution ought to be exercised in adopting any
 =  critical extensions in certificates that might prevent use in a
 =  general context.

 =  Each extension includes an OID and an ASN.1 structure.  When an=
 =  extension appears in a certificate, the OID appears as the field
 =  extnID and the corresponding ASN.1 DER encoded structure is the valu= e
 =  of the octet string extnValue.  A certificate MUST NOT include = more
 =  than one instance of a particular extension.  For example, a
 =  certificate may contain only one authority key identifier extension<= /span>
 =  (Section 4.2.1.1).  An extension includes the boolean critical,= with
 =  a default value of FALSE.  The text for each extension specifie= s the
 =  acceptable values for the critical field for CAs conforming to this<= /span>
 =  profile.

 =  Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and
 =  4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section
 =  4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. &nb= sp;If
 =  the CA issues certificates with an empty sequence for the subject
 =  field, the CA MUST support the subject alternative name extension
 =  (Section 4.2.1.6).  Support for the remaining extensions is OPT= IONAL.
 =  Conforming CAs MAY support extensions that are not identified within=
 =  this specification; certificate issuers are cautioned that marking
 =  such extensions as critical may inhibit interoperability.

 =  At a minimum, applications conforming to this profile MUST recognize=
 =  the following extensions: key usage (Section 4.2.1.3), certificate
 =  policies (Section 4.2.1.4), subject alternative name (Section
 =  4.2.1.6), basic constraints (Section 4.2.1.9), name constraints
 =  (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended<= /span>
 =  key usage (Section 4.2.1.12), and inhibit anyPolicy (Section
 =  4.2.1.14).

 =  In addition, applications conforming to this profile SHOULD recogniz= e
 =  the authority and subject key identifier (Sections 4.2.1.1 and
 =  4.2.1.2) and policy mappings (Section 4.2.1.5) extensions.

4.2.1.=  Standard Extensions

 =  This section identifies standard certificate extensions defined in
 =  [X.509] for use in the Internet PKI.  


EXTRACT FROM X.509 page 14:

The extensions field allows addition of new fields to the struct= ure without modification to the ASN.1 definition.
An extension field consists of an extension identifier, a criticality flag,= and an encoding of a data value of
an ASN.1 type associated with the identified extension.

For those extensions where ordering of individual extensions wit= hin the SEQUENCE is significant,
the specification of those individual extensions shall include the rules fo= r the significance of the order therein.

When an implementation processing a certificate does not recogni= ze an extension, if the criticality flag is FALSE,
it may ignore that extension. If the criticality flag is TRUE, unrecognized= extensions shall cause the structure
to be considered invalid, i.e., in a certificate, an unrecognized critical = extension would cause validation of
a signature using that certificate to fail.

When a certificate-using implementation recognizes and is able t= o process an extension, then the
certificate-using implementation shall process the extension regardless of = the value of the criticality flag.

Note that any extension that is flagged non-critical will cause = inconsistent behaviour between certificate-using
systems that will process the extension and certificate-using systems that = do not recognize the extension and will ignore it.

If unknown elements appear within the extension, and the extensi= on is not marked critical, those unknown elements
shall be ignored according to the rules of extensibility documented in 12.2= .2 in ITU-T Rec. X.519 | ISO/IEC 9594-5.


Denis
 

--_000_AA6BA445CBFDB84785CC1C45DAAE4C79263524CFCH1PRD0610MB393_-- From sharon.boeyen@entrust.com Mon Aug 27 10:08:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5392021F853F for ; Mon, 27 Aug 2012 10:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK+pKTV5gmDj for ; Mon, 27 Aug 2012 10:08:52 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 66F2621F852B for ; Mon, 27 Aug 2012 10:08:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,321,1344225600"; d="scan'208,217";a="6028066" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 27 Aug 2012 13:08:49 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Mon, 27 Aug 2012 13:08:49 -0400 From: Sharon Boeyen To: Russ Housley Thread-Topic: [pkix] Errata in section 5.3 from RFC 5280 Thread-Index: AQHNgWwH3CKKlFKDe0yhDO+TlkrrvJdt1YVggABQjwD//8NkkA== Date: Mon, 27 Aug 2012 17:08:48 +0000 Message-ID: <65DA4BEA501AFC409DF274CC71ED01A53A551FA6@SOTTEXCH10.corp.ad.entrust.com> References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> <65DA4BEA501AFC409DF274CC71ED01A53A551F2B@SOTTEXCH10.corp.ad.entrust.com> <4918BCF9-2556-4E9F-9398-2222E62D7E14@vigilsec.com> In-Reply-To: <4918BCF9-2556-4E9F-9398-2222E62D7E14@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.161.14] Content-Type: multipart/alternative; boundary="_000_65DA4BEA501AFC409DF274CC71ED01A53A551FA6SOTTEXCH10corpa_" MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 17:08:56 -0000 --_000_65DA4BEA501AFC409DF274CC71ED01A53A551FA6SOTTEXCH10corpa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the easiest way to clarify it would be: a) In the penultimate sentence of the first paragraph of 5.3 replace "= status of any certificate" with "status of this certificate" b) Add a new second paragraph in 5.3 that states "If an extension affe= cts the treatment of the list (e.g., multiple CRLs need to be scanned to ex= amine the entire list of revoked certificates, or an entry may represent a = range of certificates), then either that extension or a related extension s= hall be indicated as critical in the crlExtensionsfield. Therefore, a criti= cal extension in the crlEntryExtensions field of an entry shall affect only= the certificate specified in that entry, unless there is a related critica= l extension in the crlExtensions field that advertises a special treatment = for it." From: Russ Housley [mailto:housley@vigilsec.com] Sent: Monday, August 27, 2012 12:42 PM To: Sharon Boeyen Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 Sharon: Thanks for digging up those words. They support the position that I have s= tated. How do you believe the clarifications document should change to express thi= s point? Russ On Aug 27, 2012, at 12:39 PM, Sharon Boeyen wrote: Russ, I realize the RFC 5280 references the 2005 edition of X.509. However = the 2009 edition (freely available athttp://www.x500standard.com/index.php?= n=3DIg.LatestAvail ) revises this text again slightly and I think makes the= intent even clearer. It states (as part of the main text and no longer a n= ote): If an extension affects the treatment of the list (e.g., multiple CRLs need= to be scanned to examine the entire list of revoked certificates, or an en= try may represent a range of certificates), then either that extension or a= related extension shall be indicated as critical in the crlExtensionsfield= . Therefore, a critical extension in the crlEntryExtensions field of an ent= ry shall affect only the certificate specified in that entry, unless there = is a related critical extension in the crlExtensions field that advertises = a special treatment for it. The only example of this situation defined in t= his Specification is the certificateIssuer CRL entry extension and the rela= ted issuingDistributionPoint CRL extension when theindirectCRL Boolean from= that extension is set to TRUE. This is clearly the case for certificateIssuer as you indicate below and as= you note below the only other 2 standard crl entry extensions are irreleva= nt as they can only ever be non-critical and affect only the single identif= ied revoked certificate. Any private extension that might be defined as a c= rlEntry extension would also have to follow that same rule to be compliant = with the base standard. I do believe the 2005 text was clear but offer this= 2009 as additional confirmation of the intent (I personally find this text= even clearer). Cheers, Sharon From: pkix-bounces@ietf.org [mailto:pkix-boun= ces@ietf.org] On Behalf Of Russ Hous= ley Sent: Thursday, August 23, 2012 4:15 PM To: Santosh Chokhani Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 Santosh: RFC 5280 describes three CRL Entry Extensions, and all of them come from X.= 509: 5.3.1. Reason Code 5.3.2. Invalidity Date 5.3.3. Certificate Issuer The first two do not have the concern that you describe, and the third one = should only be present if the CRL includes the IssuingDistributionPoint CRL= extension, and that extension includes the indirectCRL set to TRUE. The I= ssuingDistributionPoint CRL extension must be critical. RFC 5280 says: The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. To my mind, the support for the critical IssuingDistributionPoint CRL exten= sion includes the proper support for the Certificate Issuer CRL entry exten= sion. Russ On Aug 23, 2012, at 4:01 PM, Santosh Chokhani wrote: Russ, The problem with Denis's proposal is that he wants to replace the text of n= ot using the CRL. I have cited a specific example in 5280 itself where an entry extension sco= pe goes beyond that of the entry. It potentially impacts subsequent entrie= s. Thus, Denis's proposal is unacceptable. If he just wanted to add the sente= nce as opposed to replace, it would be fine. In general, unless 5280 and X.509 stated that an entry extension cannot imp= act semantics of anything in the CRL other than the entry itself, what you = say is unacceptable and potentially insecure. From: pkix-bounces@ietf.org [mailto:pkix-boun= ces@ietf.org] On Behalf Of Russ Hous= ley Sent: Thursday, August 23, 2012 3:50 PM To: denis.pinkas@bull.net Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 I agree with the proposal that Denis makes. I support his proposed text. This validates my text proposal which still is: If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL entry to determine the status of this certificate". : Russ --_000_65DA4BEA501AFC409DF274CC71ED01A53A551FA6SOTTEXCH10corpa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think the easiest way t= o clarify it would be:

 <= /p>

a) = ;     In the penultimat= e sentence of the first paragraph of 5.3 replace “status of any certi= ficate” with “status of this certificate”

b) = ;     Add a new second = paragraph in 5.3 that states “If an extension affects the treatment of the list (e.g., multiple CRLs need t= o be scanned to examine the entire list of revoked certificates, or an entr= y may represent a range of certificates), then either that extension or a r= elated extension shall be indicated as critical in the crlExt= ensionsfield. Therefore, a critical extension in the crlEntryExtensions <= /span>field of an entry shall affect only the certificate specified in that entry, unl= ess there is a related critical extension in the crlExtensions field that advertises a special treatment for it.”<= /span>

 <= /p>

From: Russ Hou= sley [mailto:housley@vigilsec.com]
Sent: Monday, August 27, 2012 12:42 PM
To: Sharon Boeyen
Cc: IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280

 

Sharon:

 

Thanks for digging up those words.  They suppor= t the position that I have stated.

 

How do you believe the clarifications document shoul= d change to express this point?

 

Russ

 

 

On Aug 27, 2012, at 12:39 PM, Sharon Boeyen wrote:



Russ, I realize the RFC 5= 280 references the 2005 edition of X.509. However the 2009 edition (freely = available athttp://www.x500standard.com/index.php?n=3DIg.LatestAvail ) revises this text again slightly and I think makes the intent even clearer= . It states (as part of the main text and no longer a note):

 <= /p>

If an extension affects= the treatment of the list (e.g., multiple CRLs need to be scanned to exami= ne the entire list of revoked certificates, or an entry may represent a ran= ge of certificates), then either that extension or a related extension shall be indicated as critical in the crlExtensionsfield. Therefore, a critical extension in the crlEntryExtensions field of an entry shall affect only the certificate specified in that entry, unl= ess there is a related critical extension in the crlExtensions field that advertises a special treatment for it. The only example of this situation defined in this Speci= fication is the certificateIss= uer CRL entry extension and the related = ;issuingDistributionPoint CRL extension when theindirectCRL&nbs= p;Boolean from that extension is set to TRUE.

 <= /p>

 <= /p>

This is clearly the case = for certificateIssuer as you indicate below and as you note below the only = other 2 standard crl entry extensions are irrelevant as they can only ever be non-critical and affect only the single identified r= evoked certificate. Any private extension that might be defined as a crlEnt= ry extension would also have to follow that same rule to be compliant with = the base standard. I do believe the 2005 text was clear but offer this 2009 as additional confirmation of = the intent (I personally find this text even clearer).

 <= /p>

Cheers,=

Sharon<= /p>

 <= /p>

 <= /p>

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org]=  On Behalf Of Russ Housl= ey
Sent: Thursday, Au= gust 23, 2012 4:15 PM
To: Santosh Chokha= ni
Cc: IETF PKIX
Subject: Re: [pkix= ] Errata in section 5.3 from RFC 5280

 

Santosh:

 

 

RFC 5280 describes three CRL Entry Extensions, and a= ll of them come from X.509:

 

   &nb= sp;        5.3.1.  Reason Code

   &nb= sp;        5.3.2.  Invalidity Date

   &nb= sp;        5.3.3.  Certificate Issuer

 

The first two do not have the concern that you descr= ibe, and the third one should only be present if the CRL includes the = IssuingDistributionPoint CRL extension, and that extension includes the ind= irectCRL set to TRUE.  The IssuingDistributionPoint CRL extension must be critical.  RFC 5280 says:

 

   The issuing distribution point is a cri= tical CRL extension that

   identifies the CRL distribution point a= nd scope for a particular CRL,

   and it indicates whether the CRL covers= revocation for end entity

   certificates only, CA certificates only= , attribute certificates only,

   or a limited set of reason codes.  = ;Although the extension is

   critical, conforming implementations ar= e not required to support this

   extension.  However, implementatio= ns that do not support this

   extension MUST either treat the status = of any certificate not listed

   on this CRL as unknown or locate anothe= r CRL that does not contain

   any unrecognized critical extensions.

 

To my mind, the support for the critical IssuingDist= ributionPoint CRL extension includes the proper support for the Certif= icate Issuer CRL entry extension.

 

Russ

 

 

On Aug 23, 2012, at 4:01 PM, Santosh Chokhani wrote:=




Russ,

 

The problem with Denis’= ;s proposal is that he wants to replace the text of not using the CRL.

 

I have cited a specific exam= ple in 5280 itself where an entry extension scope goes beyond that of the e= ntry.  It potentially impacts subsequent entries.

 

Thus, Denis’s proposal= is unacceptable.  If he just wanted to add the sentence as opposed to= replace, it would be fine.

 

In general, unless 5280 and = X.509 stated that an entry extension cannot impact semantics of anything in= the CRL other than the entry itself, what you say is unacceptable and potentially insecure.

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org]=  On Behalf Of Russ Housl= ey
Sent: Thursday, Au= gust 23, 2012 3:50 PM
To: denis.pinkas@bull.net
Cc: IETF PKIX
Subject: Re: [pkix= ] Errata in section 5.3 from RFC 5280

 

 

I agree with the proposal that Denis makes.  I = support his proposed text.

 

This val= idates my text proposal which still is: 

   If a CRL contains = a critical CRL entry extension that the application 
  cannot process, then the= application MUST NOT use that CRL entry to
  determine the status of = this certificate". : <= /o:p>

 

Russ

 

 

--_000_65DA4BEA501AFC409DF274CC71ED01A53A551FA6SOTTEXCH10corpa_-- From denis.pinkas@bull.net Mon Aug 27 10:19:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5620221F8551 for ; Mon, 27 Aug 2012 10:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCD5PKajn9rM for ; Mon, 27 Aug 2012 10:19:47 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8C50621F8535 for ; Mon, 27 Aug 2012 10:19:46 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id A92A81807F; Mon, 27 Aug 2012 19:19:45 +0200 (CEST) In-Reply-To: <65DA4BEA501AFC409DF274CC71ED01A53A551FA6@SOTTEXCH10.corp.ad.entrust.com> References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> <65DA4BEA501AFC409DF274CC71ED01A53A551F2B@SOTTEXCH10.corp.ad.entrust.com> <4918BCF9-2556-4E9F-9398-2222E62D7E14@vigilsec.com> <65DA4BEA501AFC409DF274CC71ED01A53A551FA6@SOTTEXCH10.corp.ad.entrust.com> To: Sharon Boeyen MIME-Version: 1.0 X-KeepSent: D1007166:5424298C-C1257A67:005ED73F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Mon, 27 Aug 2012 19:19:44 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 27/08/2012 19:19:45, Serialize complete at 27/08/2012 19:19:45 Content-Type: multipart/alternative; boundary="=_alternative 005F2E5EC1257A67_=" Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 17:19:48 -0000 Message en plusieurs parties au format MIME --=_alternative 005F2E5EC1257A67_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U2hhcm9uLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBwcm9wb3NhbC4NCg0KSSBiZWxpZXZlIHRoYXQg YSBzaW1wbGlmaWNhdGlvbiB3b3VsZCBiZSBwb3NzaWJsZSwgc2luY2Ugd2UgZG8gbm90IA0KZGVz Y3JpYmUgYWxsIHRoZSBmZWF0dXJlcyBvZiAgWC41MDkgaW4gUkZDIDUyODA6DQoNCmEpICAgICAg SW4gdGhlIHBlbnVsdGltYXRlIHNlbnRlbmNlIG9mIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgNS4z IHJlcGxhY2UgDQrigJxzdGF0dXMgb2YgYW55IGNlcnRpZmljYXRl4oCdIHdpdGgg4oCcc3RhdHVz IG9mIHRoaXMgY2VydGlmaWNhdGXigJ0gDQpiKSAgICAgIEFkZCBhIG5ldyBzZWNvbmQgcGFyYWdy YXBoIGluIDUuMyB0aGF0IHN0YXRlcyDigJxUaGVyZWZvcmUsIGEgDQpjcml0aWNhbCBleHRlbnNp b24gaW4gdGhlIGNybEVudHJ5RXh0ZW5zaW9ucyBmaWVsZCBvZiBhbiBlbnRyeQ0KIHNoYWxsIGFm ZmVjdCBvbmx5IHRoZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQgaW4gdGhhdCBlbnRyeSwgdW5sZXNz IHRoZXJlIA0KaXMgYSByZWxhdGVkIGNyaXRpY2FsIGV4dGVuc2lvbiBpbiB0aGUgY3JsRXh0ZW5z aW9ucyBmaWVsZCANCnRoYXQgYWR2ZXJ0aXNlcyBhIHNwZWNpYWwgdHJlYXRtZW50IGZvciBpdC7i gJ0NCg0KRGVuaXMNCg0KDQoNCkRlIDogICAgU2hhcm9uIEJvZXllbiA8c2hhcm9uLmJvZXllbkBl bnRydXN0LmNvbT4NCkEgOiAgICAgUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNvbT4N CkNjIDogICAgSUVURiBQS0lYIDxwa2l4QGlldGYub3JnPg0KRGF0ZSA6ICAyNy8wOC8yMDEyIDE5 OjA5DQpPYmpldCA6IFJlOiBbcGtpeF0gRXJyYXRhIGluIHNlY3Rpb24gNS4zIGZyb20gUkZDIDUy ODANCkVudm95w6kgcGFyIDogICAgcGtpeC1ib3VuY2VzQGlldGYub3JnDQoNCg0KDQpJIHRoaW5r IHRoZSBlYXNpZXN0IHdheSB0byBjbGFyaWZ5IGl0IHdvdWxkIGJlOg0KIA0KYSkgICAgICBJbiB0 aGUgcGVudWx0aW1hdGUgc2VudGVuY2Ugb2YgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiA1LjMgcmVw bGFjZSANCuKAnHN0YXR1cyBvZiBhbnkgY2VydGlmaWNhdGXigJ0gd2l0aCDigJxzdGF0dXMgb2Yg dGhpcyBjZXJ0aWZpY2F0ZeKAnSANCmIpICAgICAgQWRkIGEgbmV3IHNlY29uZCBwYXJhZ3JhcGgg aW4gNS4zIHRoYXQgc3RhdGVzIOKAnElmIGFuIGV4dGVuc2lvbiANCmFmZmVjdHMgdGhlIHRyZWF0 bWVudCBvZiB0aGUgbGlzdCAoZS5nLiwgbXVsdGlwbGUgQ1JMcyBuZWVkIHRvIGJlIHNjYW5uZWQg DQp0byBleGFtaW5lIHRoZSBlbnRpcmUgbGlzdCBvZiByZXZva2VkIGNlcnRpZmljYXRlcywgb3Ig YW4gZW50cnkgbWF5IA0KcmVwcmVzZW50IGEgcmFuZ2Ugb2YgY2VydGlmaWNhdGVzKSwgdGhlbiBl aXRoZXIgdGhhdCBleHRlbnNpb24gb3IgYSANCnJlbGF0ZWQgZXh0ZW5zaW9uIHNoYWxsIGJlIGlu ZGljYXRlZCBhcyBjcml0aWNhbCBpbiB0aGUgY3JsRXh0ZW5zaW9ucw0KZmllbGQuIFRoZXJlZm9y ZSwgYSBjcml0aWNhbCBleHRlbnNpb24gaW4gdGhlIGNybEVudHJ5RXh0ZW5zaW9ucyBmaWVsZCBv ZiANCmFuIGVudHJ5IHNoYWxsIGFmZmVjdCBvbmx5IHRoZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQg aW4gdGhhdCBlbnRyeSwgdW5sZXNzIA0KdGhlcmUgaXMgYSByZWxhdGVkIGNyaXRpY2FsIGV4dGVu c2lvbiBpbiB0aGUgY3JsRXh0ZW5zaW9ucyBmaWVsZCB0aGF0IA0KYWR2ZXJ0aXNlcyBhIHNwZWNp YWwgdHJlYXRtZW50IGZvciBpdC7igJ0NCiANCkZyb206IFJ1c3MgSG91c2xleSBbbWFpbHRvOmhv dXNsZXlAdmlnaWxzZWMuY29tXSANClNlbnQ6IE1vbmRheSwgQXVndXN0IDI3LCAyMDEyIDEyOjQy IFBNDQpUbzogU2hhcm9uIEJvZXllbg0KQ2M6IElFVEYgUEtJWA0KU3ViamVjdDogUmU6IFtwa2l4 XSBFcnJhdGEgaW4gc2VjdGlvbiA1LjMgZnJvbSBSRkMgNTI4MA0KIA0KU2hhcm9uOg0KIA0KVGhh bmtzIGZvciBkaWdnaW5nIHVwIHRob3NlIHdvcmRzLiAgVGhleSBzdXBwb3J0IHRoZSBwb3NpdGlv biB0aGF0IEkgaGF2ZSANCnN0YXRlZC4NCiANCkhvdyBkbyB5b3UgYmVsaWV2ZSB0aGUgY2xhcmlm aWNhdGlvbnMgZG9jdW1lbnQgc2hvdWxkIGNoYW5nZSB0byBleHByZXNzIA0KdGhpcyBwb2ludD8N CiANClJ1c3MNCiANCiANCk9uIEF1ZyAyNywgMjAxMiwgYXQgMTI6MzkgUE0sIFNoYXJvbiBCb2V5 ZW4gd3JvdGU6DQoNCg0KUnVzcywgSSByZWFsaXplIHRoZSBSRkMgNTI4MCByZWZlcmVuY2VzIHRo ZSAyMDA1IGVkaXRpb24gb2YgWC41MDkuIEhvd2V2ZXIgDQp0aGUgMjAwOSBlZGl0aW9uIChmcmVl bHkgYXZhaWxhYmxlIGF0DQpodHRwOi8vd3d3Lng1MDBzdGFuZGFyZC5jb20vaW5kZXgucGhwP249 SWcuTGF0ZXN0QXZhaWwgKSByZXZpc2VzIHRoaXMgdGV4dCANCmFnYWluIHNsaWdodGx5IGFuZCBJ IHRoaW5rIG1ha2VzIHRoZSBpbnRlbnQgZXZlbiBjbGVhcmVyLiBJdCBzdGF0ZXMgKGFzIA0KcGFy dCBvZiB0aGUgbWFpbiB0ZXh0IGFuZCBubyBsb25nZXIgYSBub3RlKToNCiANCklmIGFuIGV4dGVu c2lvbiBhZmZlY3RzIHRoZSB0cmVhdG1lbnQgb2YgdGhlIGxpc3QgKGUuZy4sIG11bHRpcGxlIENS THMgDQpuZWVkIHRvIGJlIHNjYW5uZWQgdG8gZXhhbWluZSB0aGUgZW50aXJlIGxpc3Qgb2YgcmV2 b2tlZCBjZXJ0aWZpY2F0ZXMsIG9yIA0KYW4gZW50cnkgbWF5IHJlcHJlc2VudCBhIHJhbmdlIG9m IGNlcnRpZmljYXRlcyksIHRoZW4gZWl0aGVyIHRoYXQgDQpleHRlbnNpb24gb3IgYSByZWxhdGVk IGV4dGVuc2lvbiBzaGFsbCBiZSBpbmRpY2F0ZWQgYXMgY3JpdGljYWwgaW4gdGhlIA0KY3JsRXh0 ZW5zaW9uc2ZpZWxkLiBUaGVyZWZvcmUsIGEgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSANCmNy bEVudHJ5RXh0ZW5zaW9ucyBmaWVsZCBvZiBhbiBlbnRyeSBzaGFsbCBhZmZlY3Qgb25seSB0aGUg Y2VydGlmaWNhdGUgDQpzcGVjaWZpZWQgaW4gdGhhdCBlbnRyeSwgdW5sZXNzIHRoZXJlIGlzIGEg cmVsYXRlZCBjcml0aWNhbCBleHRlbnNpb24gaW4gDQp0aGUgY3JsRXh0ZW5zaW9ucyBmaWVsZCB0 aGF0IGFkdmVydGlzZXMgYSBzcGVjaWFsIHRyZWF0bWVudCBmb3IgaXQuIFRoZSANCm9ubHkgZXhh bXBsZSBvZiB0aGlzIHNpdHVhdGlvbiBkZWZpbmVkIGluIHRoaXMgU3BlY2lmaWNhdGlvbiBpcyB0 aGUgDQpjZXJ0aWZpY2F0ZUlzc3VlciBDUkwgZW50cnkgZXh0ZW5zaW9uIGFuZCB0aGUgcmVsYXRl ZCANCmlzc3VpbmdEaXN0cmlidXRpb25Qb2ludCBDUkwgZXh0ZW5zaW9uIHdoZW4gdGhlaW5kaXJl Y3RDUkwgQm9vbGVhbiBmcm9tIA0KdGhhdCBleHRlbnNpb24gaXMgc2V0IHRvIFRSVUUuDQogDQog DQpUaGlzIGlzIGNsZWFybHkgdGhlIGNhc2UgZm9yIGNlcnRpZmljYXRlSXNzdWVyIGFzIHlvdSBp bmRpY2F0ZSBiZWxvdyBhbmQgDQphcyB5b3Ugbm90ZSBiZWxvdyB0aGUgb25seSBvdGhlciAyIHN0 YW5kYXJkIGNybCBlbnRyeSBleHRlbnNpb25zIGFyZSANCmlycmVsZXZhbnQgYXMgdGhleSBjYW4g b25seSBldmVyIGJlIG5vbi1jcml0aWNhbCBhbmQgYWZmZWN0IG9ubHkgdGhlIA0Kc2luZ2xlIGlk ZW50aWZpZWQgcmV2b2tlZCBjZXJ0aWZpY2F0ZS4gQW55IHByaXZhdGUgZXh0ZW5zaW9uIHRoYXQg bWlnaHQgYmUgDQpkZWZpbmVkIGFzIGEgY3JsRW50cnkgZXh0ZW5zaW9uIHdvdWxkIGFsc28gaGF2 ZSB0byBmb2xsb3cgdGhhdCBzYW1lIHJ1bGUgDQp0byBiZSBjb21wbGlhbnQgd2l0aCB0aGUgYmFz ZSBzdGFuZGFyZC4gSSBkbyBiZWxpZXZlIHRoZSAyMDA1IHRleHQgd2FzIA0KY2xlYXIgYnV0IG9m ZmVyIHRoaXMgMjAwOSBhcyBhZGRpdGlvbmFsIGNvbmZpcm1hdGlvbiBvZiB0aGUgaW50ZW50IChJ IA0KcGVyc29uYWxseSBmaW5kIHRoaXMgdGV4dCBldmVuIGNsZWFyZXIpLg0KIA0KQ2hlZXJzLA0K U2hhcm9uDQogDQogDQpGcm9tOiBwa2l4LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwa2l4LWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANClJ1c3MgSG91c2xleQ0KU2VudDogVGh1cnNk YXksIEF1Z3VzdCAyMywgMjAxMiA0OjE1IFBNDQpUbzogU2FudG9zaCBDaG9raGFuaQ0KQ2M6IElF VEYgUEtJWA0KU3ViamVjdDogUmU6IFtwa2l4XSBFcnJhdGEgaW4gc2VjdGlvbiA1LjMgZnJvbSBS RkMgNTI4MA0KIA0KU2FudG9zaDoNCiANCiANClJGQyA1MjgwIGRlc2NyaWJlcyB0aHJlZSBDUkwg RW50cnkgRXh0ZW5zaW9ucywgYW5kIGFsbCBvZiB0aGVtIGNvbWUgZnJvbSANClguNTA5Og0KIA0K ICAgICAgICAgICAgNS4zLjEuICBSZWFzb24gQ29kZQ0KICAgICAgICAgICAgNS4zLjIuICBJbnZh bGlkaXR5IERhdGUNCiAgICAgICAgICAgIDUuMy4zLiAgQ2VydGlmaWNhdGUgSXNzdWVyDQogDQpU aGUgZmlyc3QgdHdvIGRvIG5vdCBoYXZlIHRoZSBjb25jZXJuIHRoYXQgeW91IGRlc2NyaWJlLCBh bmQgdGhlIHRoaXJkIG9uZSANCnNob3VsZCBvbmx5IGJlIHByZXNlbnQgaWYgdGhlIENSTCBpbmNs dWRlcyB0aGUgSXNzdWluZ0Rpc3RyaWJ1dGlvblBvaW50IA0KQ1JMIGV4dGVuc2lvbiwgYW5kIHRo YXQgZXh0ZW5zaW9uIGluY2x1ZGVzIHRoZSBpbmRpcmVjdENSTCBzZXQgdG8gVFJVRS4gDQpUaGUg SXNzdWluZ0Rpc3RyaWJ1dGlvblBvaW50IENSTCBleHRlbnNpb24gbXVzdCBiZSBjcml0aWNhbC4g IFJGQyA1MjgwIA0Kc2F5czoNCiANCiAgIFRoZSBpc3N1aW5nIGRpc3RyaWJ1dGlvbiBwb2ludCBp cyBhIGNyaXRpY2FsIENSTCBleHRlbnNpb24gdGhhdA0KICAgaWRlbnRpZmllcyB0aGUgQ1JMIGRp c3RyaWJ1dGlvbiBwb2ludCBhbmQgc2NvcGUgZm9yIGEgcGFydGljdWxhciBDUkwsDQogICBhbmQg aXQgaW5kaWNhdGVzIHdoZXRoZXIgdGhlIENSTCBjb3ZlcnMgcmV2b2NhdGlvbiBmb3IgZW5kIGVu dGl0eQ0KICAgY2VydGlmaWNhdGVzIG9ubHksIENBIGNlcnRpZmljYXRlcyBvbmx5LCBhdHRyaWJ1 dGUgY2VydGlmaWNhdGVzIG9ubHksDQogICBvciBhIGxpbWl0ZWQgc2V0IG9mIHJlYXNvbiBjb2Rl cy4gIEFsdGhvdWdoIHRoZSBleHRlbnNpb24gaXMNCiAgIGNyaXRpY2FsLCBjb25mb3JtaW5nIGlt cGxlbWVudGF0aW9ucyBhcmUgbm90IHJlcXVpcmVkIHRvIHN1cHBvcnQgdGhpcw0KICAgZXh0ZW5z aW9uLiAgSG93ZXZlciwgaW1wbGVtZW50YXRpb25zIHRoYXQgZG8gbm90IHN1cHBvcnQgdGhpcw0K ICAgZXh0ZW5zaW9uIE1VU1QgZWl0aGVyIHRyZWF0IHRoZSBzdGF0dXMgb2YgYW55IGNlcnRpZmlj YXRlIG5vdCBsaXN0ZWQNCiAgIG9uIHRoaXMgQ1JMIGFzIHVua25vd24gb3IgbG9jYXRlIGFub3Ro ZXIgQ1JMIHRoYXQgZG9lcyBub3QgY29udGFpbg0KICAgYW55IHVucmVjb2duaXplZCBjcml0aWNh bCBleHRlbnNpb25zLg0KIA0KVG8gbXkgbWluZCwgdGhlIHN1cHBvcnQgZm9yIHRoZSBjcml0aWNh bCBJc3N1aW5nRGlzdHJpYnV0aW9uUG9pbnQgQ1JMIA0KZXh0ZW5zaW9uIGluY2x1ZGVzIHRoZSBw cm9wZXIgc3VwcG9ydCBmb3IgdGhlIENlcnRpZmljYXRlIElzc3VlciBDUkwgZW50cnkgDQpleHRl bnNpb24uDQogDQpSdXNzDQogDQogDQpPbiBBdWcgMjMsIDIwMTIsIGF0IDQ6MDEgUE0sIFNhbnRv c2ggQ2hva2hhbmkgd3JvdGU6DQoNCg0KDQpSdXNzLA0KIA0KVGhlIHByb2JsZW0gd2l0aCBEZW5p c+KAmXMgcHJvcG9zYWwgaXMgdGhhdCBoZSB3YW50cyB0byByZXBsYWNlIHRoZSB0ZXh0IG9mIA0K bm90IHVzaW5nIHRoZSBDUkwuDQogDQpJIGhhdmUgY2l0ZWQgYSBzcGVjaWZpYyBleGFtcGxlIGlu IDUyODAgaXRzZWxmIHdoZXJlIGFuIGVudHJ5IGV4dGVuc2lvbiANCnNjb3BlIGdvZXMgYmV5b25k IHRoYXQgb2YgdGhlIGVudHJ5LiAgSXQgcG90ZW50aWFsbHkgaW1wYWN0cyBzdWJzZXF1ZW50IA0K ZW50cmllcy4NCiANClRodXMsIERlbmlz4oCZcyBwcm9wb3NhbCBpcyB1bmFjY2VwdGFibGUuICBJ ZiBoZSBqdXN0IHdhbnRlZCB0byBhZGQgdGhlIA0Kc2VudGVuY2UgYXMgb3Bwb3NlZCB0byByZXBs YWNlLCBpdCB3b3VsZCBiZSBmaW5lLg0KIA0KSW4gZ2VuZXJhbCwgdW5sZXNzIDUyODAgYW5kIFgu NTA5IHN0YXRlZCB0aGF0IGFuIGVudHJ5IGV4dGVuc2lvbiBjYW5ub3QgDQppbXBhY3Qgc2VtYW50 aWNzIG9mIGFueXRoaW5nIGluIHRoZSBDUkwgb3RoZXIgdGhhbiB0aGUgZW50cnkgaXRzZWxmLCB3 aGF0IA0KeW91IHNheSBpcyB1bmFjY2VwdGFibGUgYW5kIHBvdGVudGlhbGx5IGluc2VjdXJlLg0K IA0KRnJvbTogcGtpeC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgDQpSdXNzIEhvdXNsZXkNClNlbnQ6IFRodXJzZGF5LCBBdWd1c3Qg MjMsIDIwMTIgMzo1MCBQTQ0KVG86IGRlbmlzLnBpbmthc0BidWxsLm5ldA0KQ2M6IElFVEYgUEtJ WA0KU3ViamVjdDogUmU6IFtwa2l4XSBFcnJhdGEgaW4gc2VjdGlvbiA1LjMgZnJvbSBSRkMgNTI4 MA0KIA0KIA0KSSBhZ3JlZSB3aXRoIHRoZSBwcm9wb3NhbCB0aGF0IERlbmlzIG1ha2VzLiAgSSBz dXBwb3J0IGhpcyBwcm9wb3NlZCB0ZXh0Lg0KIA0KVGhpcyB2YWxpZGF0ZXMgbXkgdGV4dCBwcm9w b3NhbCB3aGljaCBzdGlsbCBpczogDQoNCiAgIElmIGEgQ1JMIGNvbnRhaW5zIGEgY3JpdGljYWwg Q1JMIGVudHJ5IGV4dGVuc2lvbiB0aGF0IHRoZSBhcHBsaWNhdGlvbiANCiAgY2Fubm90IHByb2Nl c3MsIHRoZW4gdGhlIGFwcGxpY2F0aW9uIE1VU1QgTk9UIHVzZSB0aGF0IENSTCBlbnRyeSB0bw0K ICBkZXRlcm1pbmUgdGhlIHN0YXR1cyBvZiB0aGlzIGNlcnRpZmljYXRlIi4gOiANCiANClJ1c3MN CiANCiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGtp eCBtYWlsaW5nIGxpc3QNCnBraXhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGtpeA0KDQoNCg== --=_alternative 005F2E5EC1257A67_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNoYXJvbiw8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rIHlvdSBmb3IgdGhlIHByb3Bvc2Fs LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBiZWxp ZXZlIHRoYXQgYSBzaW1wbGlmaWNhdGlvbiB3b3VsZA0KYmUgcG9zc2libGUsIHNpbmNlIHdlIGRv IG5vdCBkZXNjcmliZSBhbGwgdGhlIGZlYXR1cmVzIG9mICZuYnNwO1guNTA5IGluDQpSRkMgNTI4 MDo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2Fs aWJyaSI+YSkgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbg0KdGhlIHBlbnVsdGltYXRlIHNlbnRlbmNl IG9mIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgNS4zIHJlcGxhY2Ug4oCcc3RhdHVzDQpvZiBhbnkg Y2VydGlmaWNhdGXigJ0gd2l0aCDigJxzdGF0dXMgb2YgdGhpcyBjZXJ0aWZpY2F0ZeKAnSA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+YikgJm5i c3A7ICZuYnNwOyAmbmJzcDtBZGQNCmEgbmV3IHNlY29uZCBwYXJhZ3JhcGggaW4gNS4zIHRoYXQg c3RhdGVzIOKAnDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzEwNDE2MCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxpPlRoZXJlZm9yZSwNCmEgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSA8L2k+ PC9mb250Pjxmb250IHNpemU9MSBjb2xvcj0jMTA0MTYwIGZhY2U9InNhbnMtc2VyaWYiPjxiPjxp PmNybEVudHJ5RXh0ZW5zaW9uczwvaT48L2I+PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jMTA0 MTYwIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGI+PGk+DQo8L2k+PC9iPjxpPmZpZWxkIG9mIGFu IGVudHJ5PGJyPg0KIHNoYWxsIGFmZmVjdCBvbmx5IHRoZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQg aW4gdGhhdCBlbnRyeSwgdW5sZXNzIHRoZXJlDQppcyBhIHJlbGF0ZWQgY3JpdGljYWwgZXh0ZW5z aW9uIGluIHRoZSA8Yj5jcmxFeHRlbnNpb25zPC9pPjwvYj48aT4gZmllbGQNCjxicj4NCnRoYXQg YWR2ZXJ0aXNlcyBhIHNwZWNpYWwgdHJlYXRtZW50IGZvciBpdC7igJ08L2k+PC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5EZW5pczwvZm9udD4NCjxicj4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNl cmlmIj5EZSA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPlNoYXJvbiBCb2V5ZW4gJmx0O3NoYXJvbi5ib2V5ZW5AZW50cnVz dC5jb20mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNh bnMtc2VyaWYiPkEgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SdXNzIEhvdXNsZXkgJmx0O2hvdXNsZXlAdmlnaWxzZWMu Y29tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5z LXNlcmlmIj5DYyZuYnNwOzogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+SUVURiBQS0lYICZsdDtwa2l4QGlldGYub3JnJmd0 OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlm Ij5EYXRlIDogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+MjcvMDgvMjAxMiAxOTowOTwvZm9udD4NCjxicj48Zm9udCBzaXpl PTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5PYmpldCA6ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBb cGtpeF0gRXJyYXRhDQppbiBzZWN0aW9uIDUuMyBmcm9tIFJGQyA1MjgwPC9mb250Pg0KPGJyPjxm b250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkVudm95w6kgcGFyIDog Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+cGtpeC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPGJyPg0KPGhyIG5vc2hhZGU+ DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJy aSI+SSB0aGluayB0aGUgZWFzaWVzdCB3YXkgdG8NCmNsYXJpZnkgaXQgd291bGQgYmU6PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5hKSAm bmJzcDsgJm5ic3A7ICZuYnNwO0luDQp0aGUgcGVudWx0aW1hdGUgc2VudGVuY2Ugb2YgdGhlIGZp cnN0IHBhcmFncmFwaCBvZiA1LjMgcmVwbGFjZSDigJxzdGF0dXMNCm9mIGFueSBjZXJ0aWZpY2F0 ZeKAnSB3aXRoIOKAnHN0YXR1cyBvZiB0aGlzIGNlcnRpZmljYXRl4oCdIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5iKSAmbmJzcDsgJm5ic3A7 ICZuYnNwO0FkZA0KYSBuZXcgc2Vjb25kIHBhcmFncmFwaCBpbiA1LjMgdGhhdCBzdGF0ZXMg4oCc PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jMTA0MTYwIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PGk+SWYNCmFuIGV4dGVuc2lvbiBhZmZlY3RzIHRoZSB0cmVhdG1lbnQgb2YgdGhlIGxpc3QgKGUu Zy4sIG11bHRpcGxlIENSTHMgbmVlZA0KdG8gYmUgc2Nhbm5lZCB0byBleGFtaW5lIHRoZSBlbnRp cmUgbGlzdCBvZiByZXZva2VkIGNlcnRpZmljYXRlcywgb3IgYW4NCmVudHJ5IG1heSByZXByZXNl bnQgYSByYW5nZSBvZiBjZXJ0aWZpY2F0ZXMpLCB0aGVuIGVpdGhlciB0aGF0IGV4dGVuc2lvbg0K b3IgYSByZWxhdGVkIGV4dGVuc2lvbiBzaGFsbCBiZSBpbmRpY2F0ZWQgYXMgY3JpdGljYWwgaW4g dGhlIDwvaT48L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSMxMDQxNjAgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+PGk+Y3JsRXh0ZW5zaW9uczwvaT48L2I+PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0j MTA0MTYwIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGk+ZmllbGQuDQpUaGVyZWZvcmUsIGEgY3Jp dGljYWwgZXh0ZW5zaW9uIGluIHRoZSA8L2k+PC9mb250Pjxmb250IHNpemU9MSBjb2xvcj0jMTA0 MTYwIGZhY2U9InNhbnMtc2VyaWYiPjxiPjxpPmNybEVudHJ5RXh0ZW5zaW9uczwvaT48L2I+PC9m b250Pjxmb250IHNpemU9MyBjb2xvcj0jMTA0MTYwIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGI+ PGk+DQo8L2k+PC9iPjxpPmZpZWxkIG9mIGFuIGVudHJ5IHNoYWxsIGFmZmVjdCBvbmx5IHRoZSBj ZXJ0aWZpY2F0ZSBzcGVjaWZpZWQNCmluIHRoYXQgZW50cnksIHVubGVzcyB0aGVyZSBpcyBhIHJl bGF0ZWQgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSA8Yj5jcmxFeHRlbnNpb25zPC9pPjwvYj48 aT4NCmZpZWxkIHRoYXQgYWR2ZXJ0aXNlcyBhIHNwZWNpYWwgdHJlYXRtZW50IGZvciBpdC7igJ08 L2k+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmki PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwv Yj4gUnVzcyBIb3VzbGV5IFs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86aG91c2xleUB2aWdpbHNlYy5j b20+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29t PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dDQo8Yj48YnI+DQpTZW50Ojwv Yj4gTW9uZGF5LCBBdWd1c3QgMjcsIDIwMTIgMTI6NDIgUE08Yj48YnI+DQpUbzo8L2I+IFNoYXJv biBCb2V5ZW48Yj48YnI+DQpDYzo8L2I+IElFVEYgUEtJWDxiPjxicj4NClN1YmplY3Q6PC9iPiBS ZTogW3BraXhdIEVycmF0YSBpbiBzZWN0aW9uIDUuMyBmcm9tIFJGQyA1MjgwPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5TaGFyb246PC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UaGFua3MgZm9yIGRpZ2dpbmcgdXAgdGhv c2Ugd29yZHMuDQombmJzcDtUaGV5IHN1cHBvcnQgdGhlIHBvc2l0aW9uIHRoYXQgSSBoYXZlIHN0 YXRlZC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkhvdyBk byB5b3UgYmVsaWV2ZSB0aGUgY2xhcmlmaWNhdGlvbnMNCmRvY3VtZW50IHNob3VsZCBjaGFuZ2Ug dG8gZXhwcmVzcyB0aGlzIHBvaW50PzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+UnVzczwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPk9uIEF1ZyAyNywgMjAxMiwgYXQgMTI6MzkgUE0sIFNoYXJvbg0KQm9leWVuIHdyb3RlOjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+UnVzcywg SSByZWFsaXplIHRoZSBSRkMgNTI4MA0KcmVmZXJlbmNlcyB0aGUgMjAwNSBlZGl0aW9uIG9mIFgu NTA5LiBIb3dldmVyIHRoZSAyMDA5IGVkaXRpb24gKGZyZWVseQ0KYXZhaWxhYmxlIGF0PC9mb250 PjxhIGhyZWY9Imh0dHA6Ly93d3cueDUwMHN0YW5kYXJkLmNvbS9pbmRleC5waHA/bj1JZy5MYXRl c3RBdmFpbCI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ2FsaWJyaSI+PHU+aHR0cDov L3d3dy54NTAwc3RhbmRhcmQuY29tL2luZGV4LnBocD9uPUlnLkxhdGVzdEF2YWlsPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+DQopIHJldmlz ZXMgdGhpcyB0ZXh0IGFnYWluIHNsaWdodGx5IGFuZCBJIHRoaW5rIG1ha2VzIHRoZSBpbnRlbnQg ZXZlbiBjbGVhcmVyLg0KSXQgc3RhdGVzIChhcyBwYXJ0IG9mIHRoZSBtYWluIHRleHQgYW5kIG5v IGxvbmdlciBhIG5vdGUpOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBm YWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPXJlZCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxpPklmIGFuIGV4dGVuc2lvbiBhZmZlY3RzDQp0aGUgdHJl YXRtZW50IG9mIHRoZSBsaXN0IChlLmcuLCBtdWx0aXBsZSBDUkxzIG5lZWQgdG8gYmUgc2Nhbm5l ZCB0byBleGFtaW5lDQp0aGUgZW50aXJlIGxpc3Qgb2YgcmV2b2tlZCBjZXJ0aWZpY2F0ZXMsIG9y IGFuIGVudHJ5IG1heSByZXByZXNlbnQgYSByYW5nZQ0Kb2YgY2VydGlmaWNhdGVzKSwgdGhlbiBl aXRoZXIgdGhhdCBleHRlbnNpb24gb3IgYSByZWxhdGVkIGV4dGVuc2lvbiBzaGFsbA0KYmUgaW5k aWNhdGVkIGFzIGNyaXRpY2FsIGluIHRoZSA8L2k+PC9mb250Pjxmb250IHNpemU9MSBjb2xvcj1y ZWQgZmFjZT0ic2Fucy1zZXJpZiI+PGI+PGk+Y3JsRXh0ZW5zaW9uczwvaT48L2I+PC9mb250Pjxm b250IHNpemU9MyBjb2xvcj1yZWQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48aT5maWVsZC4NClRo ZXJlZm9yZSwgYSBjcml0aWNhbCBleHRlbnNpb24gaW4gdGhlIDwvaT48L2ZvbnQ+PGZvbnQgc2l6 ZT0xIGNvbG9yPXJlZCBmYWNlPSJzYW5zLXNlcmlmIj48Yj48aT5jcmxFbnRyeUV4dGVuc2lvbnM8 L2k+PC9iPjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9cmVkIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PGI+PGk+DQo8L2k+PC9iPjxpPmZpZWxkIG9mIGFuIGVudHJ5IHNoYWxsIGFmZmVjdCBvbmx5 IHRoZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQNCmluIHRoYXQgZW50cnksIHVubGVzcyB0aGVyZSBp cyBhIHJlbGF0ZWQgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSA8Yj5jcmxFeHRlbnNpb25zPC9p PjwvYj48aT4NCmZpZWxkIHRoYXQgYWR2ZXJ0aXNlcyBhIHNwZWNpYWwgdHJlYXRtZW50IGZvciBp dC4gVGhlIG9ubHkgZXhhbXBsZSBvZiB0aGlzDQpzaXR1YXRpb24gZGVmaW5lZCBpbiB0aGlzIFNw ZWNpZmljYXRpb24gaXMgdGhlIDwvaT48L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPXJlZCBmYWNl PSJzYW5zLXNlcmlmIj48Yj48aT5jZXJ0aWZpY2F0ZUlzc3VlcjwvaT48L2I+PC9mb250Pjxmb250 IHNpemU9MyBjb2xvcj1yZWQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48aT4NCkNSTCBlbnRyeSBl eHRlbnNpb24gYW5kIHRoZSByZWxhdGVkIDwvaT48L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPXJl ZCBmYWNlPSJzYW5zLXNlcmlmIj48Yj48aT5pc3N1aW5nRGlzdHJpYnV0aW9uUG9pbnQ8L2k+PC9i PjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9cmVkIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGk+ DQpDUkwgZXh0ZW5zaW9uIHdoZW4gdGhlPGI+aW5kaXJlY3RDUkwgPC9pPjwvYj48aT5Cb29sZWFu IGZyb20gdGhhdCBleHRlbnNpb24NCmlzIHNldCB0byA8L2k+PC9mb250Pjxmb250IHNpemU9MSBj b2xvcj1yZWQgZmFjZT0ic2Fucy1zZXJpZiI+PGI+PGk+VFJVRTwvaT48L2I+PC9mb250Pjxmb250 IHNpemU9MyBjb2xvcj1yZWQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48aT4uPC9pPjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPlRo aXMgaXMgY2xlYXJseSB0aGUgY2FzZQ0KZm9yIGNlcnRpZmljYXRlSXNzdWVyIGFzIHlvdSBpbmRp Y2F0ZSBiZWxvdyBhbmQgYXMgeW91IG5vdGUgYmVsb3cgdGhlIG9ubHkNCm90aGVyIDIgc3RhbmRh cmQgY3JsIGVudHJ5IGV4dGVuc2lvbnMgYXJlIGlycmVsZXZhbnQgYXMgdGhleSBjYW4gb25seSBl dmVyDQpiZSBub24tY3JpdGljYWwgYW5kIGFmZmVjdCBvbmx5IHRoZSBzaW5nbGUgaWRlbnRpZmll ZCByZXZva2VkIGNlcnRpZmljYXRlLg0KQW55IHByaXZhdGUgZXh0ZW5zaW9uIHRoYXQgbWlnaHQg YmUgZGVmaW5lZCBhcyBhIGNybEVudHJ5IGV4dGVuc2lvbiB3b3VsZA0KYWxzbyBoYXZlIHRvIGZv bGxvdyB0aGF0IHNhbWUgcnVsZSB0byBiZSBjb21wbGlhbnQgd2l0aCB0aGUgYmFzZSBzdGFuZGFy ZC4NCkkgZG8gYmVsaWV2ZSB0aGUgMjAwNSB0ZXh0IHdhcyBjbGVhciBidXQgb2ZmZXIgdGhpcyAy MDA5IGFzIGFkZGl0aW9uYWwNCmNvbmZpcm1hdGlvbiBvZiB0aGUgaW50ZW50IChJIHBlcnNvbmFs bHkgZmluZCB0aGlzIHRleHQgZXZlbiBjbGVhcmVyKS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPkNoZWVycyw8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+U2hhcm9uPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IDwvZm9udD48 YSBocmVmPSJtYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PnBraXgtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9h Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPg0KPC9mb250PjxhIGhyZWY9Im1haWx0bzpbbWFp bHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZ10iPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 IlRhaG9tYSI+PHU+W21haWx0bzpwa2l4LWJvdW5jZXNAaWV0Zi5vcmddPC91PjwvZm9udD48L2E+ PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJ1c3MgSG91 c2xleTxiPjxicj4NClNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDIzLCAyMDEyIDQ6MTUgUE08 Yj48YnI+DQpUbzo8L2I+IFNhbnRvc2ggQ2hva2hhbmk8Yj48YnI+DQpDYzo8L2I+IElFVEYgUEtJ WDxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW3BraXhdIEVycmF0YSBpbiBzZWN0aW9uIDUuMyBm cm9tIFJGQyA1MjgwPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij5TYW50b3NoOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlJG QyA1MjgwIGRlc2NyaWJlcyB0aHJlZSBDUkwgRW50cnkNCkV4dGVuc2lvbnMsIGFuZCBhbGwgb2Yg dGhlbSBjb21lIGZyb20gWC41MDk6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgNS4z LjEuICZuYnNwO1JlYXNvbiBDb2RlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyA1 LjMuMi4gJm5ic3A7SW52YWxpZGl0eSBEYXRlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyA1LjMuMy4gJm5ic3A7Q2VydGlmaWNhdGUgSXNzdWVyPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UaGUgZmlyc3QgdHdvIGRvIG5vdCBoYXZlIHRoZSBj b25jZXJuDQp0aGF0IHlvdSBkZXNjcmliZSwgYW5kIHRoZSB0aGlyZCBvbmUgc2hvdWxkIG9ubHkg YmUgcHJlc2VudCBpZiB0aGUgQ1JMDQppbmNsdWRlcyB0aGUgSXNzdWluZ0Rpc3RyaWJ1dGlvblBv aW50IENSTCBleHRlbnNpb24sIGFuZCB0aGF0IGV4dGVuc2lvbg0KaW5jbHVkZXMgdGhlIGluZGly ZWN0Q1JMIHNldCB0byBUUlVFLiAmbmJzcDtUaGUgSXNzdWluZ0Rpc3RyaWJ1dGlvblBvaW50DQpD UkwgZXh0ZW5zaW9uIG11c3QgYmUgY3JpdGljYWwuICZuYnNwO1JGQyA1MjgwIHNheXM6PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDsgJm5ic3A7VGhl IGlzc3VpbmcgZGlzdHJpYnV0aW9uDQpwb2ludCBpcyBhIGNyaXRpY2FsIENSTCBleHRlbnNpb24g dGhhdDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJz cDsgJm5ic3A7aWRlbnRpZmllcyB0aGUgQ1JMDQpkaXN0cmlidXRpb24gcG9pbnQgYW5kIHNjb3Bl IGZvciBhIHBhcnRpY3VsYXIgQ1JMLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4mbmJzcDsgJm5ic3A7YW5kIGl0IGluZGljYXRlcyB3aGV0aGVyDQp0aGUg Q1JMIGNvdmVycyByZXZvY2F0aW9uIGZvciBlbmQgZW50aXR5PC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOyAmbmJzcDtjZXJ0aWZpY2F0ZXMgb25s eSwNCkNBIGNlcnRpZmljYXRlcyBvbmx5LCBhdHRyaWJ1dGUgY2VydGlmaWNhdGVzIG9ubHksPC9m b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOyAmbmJz cDtvciBhIGxpbWl0ZWQgc2V0IG9mDQpyZWFzb24gY29kZXMuICZuYnNwO0FsdGhvdWdoIHRoZSBl eHRlbnNpb24gaXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+Jm5ic3A7ICZuYnNwO2NyaXRpY2FsLCBjb25mb3JtaW5nDQppbXBsZW1lbnRhdGlvbnMgYXJl IG5vdCByZXF1aXJlZCB0byBzdXBwb3J0IHRoaXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7ICZuYnNwO2V4dGVuc2lvbi4gJm5ic3A7SG93ZXZl ciwNCmltcGxlbWVudGF0aW9ucyB0aGF0IGRvIG5vdCBzdXBwb3J0IHRoaXM8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7ICZuYnNwO2V4dGVuc2lv biBNVVNUIGVpdGhlcg0KdHJlYXQgdGhlIHN0YXR1cyBvZiBhbnkgY2VydGlmaWNhdGUgbm90IGxp c3RlZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJz cDsgJm5ic3A7b24gdGhpcyBDUkwgYXMgdW5rbm93bg0Kb3IgbG9jYXRlIGFub3RoZXIgQ1JMIHRo YXQgZG9lcyBub3QgY29udGFpbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4mbmJzcDsgJm5ic3A7YW55IHVucmVjb2duaXplZCBjcml0aWNhbA0KZXh0ZW5z aW9ucy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRvIG15 IG1pbmQsIHRoZSBzdXBwb3J0IGZvciB0aGUNCmNyaXRpY2FsIElzc3VpbmdEaXN0cmlidXRpb25Q b2ludCBDUkwgZXh0ZW5zaW9uIGluY2x1ZGVzIHRoZSBwcm9wZXIgc3VwcG9ydA0KZm9yIHRoZSBD ZXJ0aWZpY2F0ZSBJc3N1ZXIgQ1JMIGVudHJ5IGV4dGVuc2lvbi48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlJ1c3M8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj5PbiBBdWcgMjMsIDIwMTIsIGF0IDQ6MDEgUE0sIFNhbnRvc2gN CkNob2toYW5pIHdyb3RlOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSMwMDQw ODAgZmFjZT0iQXJpYWwiPlJ1c3MsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jMDA0 MDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSMw MDQwODAgZmFjZT0iQXJpYWwiPlRoZSBwcm9ibGVtIHdpdGggRGVuaXPigJlzIHByb3Bvc2FsDQpp cyB0aGF0IGhlIHdhbnRzIHRvIHJlcGxhY2UgdGhlIHRleHQgb2Ygbm90IHVzaW5nIHRoZSBDUkwu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jMDA0MDgwIGZhY2U9IkFyaWFsIj4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSMwMDQwODAgZmFjZT0iQXJpYWwiPkkg aGF2ZSBjaXRlZCBhIHNwZWNpZmljIGV4YW1wbGUNCmluIDUyODAgaXRzZWxmIHdoZXJlIGFuIGVu dHJ5IGV4dGVuc2lvbiBzY29wZSBnb2VzIGJleW9uZCB0aGF0IG9mIHRoZSBlbnRyeS4NCiZuYnNw O0l0IHBvdGVudGlhbGx5IGltcGFjdHMgc3Vic2VxdWVudCBlbnRyaWVzLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTEgY29sb3I9IzAwNDA4MCBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MSBjb2xvcj0jMDA0MDgwIGZhY2U9IkFyaWFsIj5UaHVzLCBEZW5pc+KAmXMg cHJvcG9zYWwgaXMNCnVuYWNjZXB0YWJsZS4gJm5ic3A7SWYgaGUganVzdCB3YW50ZWQgdG8gYWRk IHRoZSBzZW50ZW5jZSBhcyBvcHBvc2VkIHRvDQpyZXBsYWNlLCBpdCB3b3VsZCBiZSBmaW5lLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzAwNDA4MCBmYWNlPSJBcmlhbCI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jMDA0MDgwIGZhY2U9IkFyaWFsIj5JbiBn ZW5lcmFsLCB1bmxlc3MgNTI4MCBhbmQNClguNTA5IHN0YXRlZCB0aGF0IGFuIGVudHJ5IGV4dGVu c2lvbiBjYW5ub3QgaW1wYWN0IHNlbWFudGljcyBvZiBhbnl0aGluZw0KaW4gdGhlIENSTCBvdGhl ciB0aGFuIHRoZSBlbnRyeSBpdHNlbGYsIHdoYXQgeW91IHNheSBpcyB1bmFjY2VwdGFibGUgYW5k DQpwb3RlbnRpYWxseSBpbnNlY3VyZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSMw MDQwODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i VGFob21hIj48Yj5Gcm9tOjwvYj4gPC9mb250PjxhIGhyZWY9Im1haWx0bzpwa2l4LWJvdW5jZXNA aWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+cGtpeC1i b3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+ DQo8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOlttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXSI+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5bbWFpbHRvOnBraXgtYm91 bmNlc0BpZXRmLm9yZ108L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4N CjxiPk9uIEJlaGFsZiBPZiA8L2I+UnVzcyBIb3VzbGV5PGI+PGJyPg0KU2VudDo8L2I+IFRodXJz ZGF5LCBBdWd1c3QgMjMsIDIwMTIgMzo1MCBQTTxiPjxicj4NClRvOjwvYj4gPC9mb250PjxhIGhy ZWY9bWFpbHRvOmRlbmlzLnBpbmthc0BidWxsLm5ldD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPSJUYWhvbWEiPjx1PmRlbmlzLnBpbmthc0BidWxsLm5ldDwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCkNjOjwvYj4gSUVURiBQS0lYPGI+PGJyPg0K U3ViamVjdDo8L2I+IFJlOiBbcGtpeF0gRXJyYXRhIGluIHNlY3Rpb24gNS4zIGZyb20gUkZDIDUy ODA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JIGFncmVlIHdp dGggdGhlIHByb3Bvc2FsIHRoYXQNCkRlbmlzIG1ha2VzLiAmbmJzcDtJIHN1cHBvcnQgaGlzIHBy b3Bvc2VkIHRleHQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPlRoaXMgdmFs aWRhdGVzIG15IHRleHQgcHJvcG9zYWwgd2hpY2ggc3RpbGwNCmlzOjwvZm9udD48Zm9udCBzaXpl PTQgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxicj4NCiAmbmJzcDsgSWYgYSBDUkwgY29udGFpbnMgYSBjcml0aWNhbCBDUkwg ZW50cnkgZXh0ZW5zaW9uIHRoYXQgdGhlIGFwcGxpY2F0aW9uDQo8YnI+DQogJm5ic3A7Y2Fubm90 IHByb2Nlc3MsIHRoZW4gdGhlIGFwcGxpY2F0aW9uIE1VU1QgTk9UIHVzZSB0aGF0IENSTCBlbnRy eQ0KdG88YnI+DQogJm5ic3A7ZGV0ZXJtaW5lIHRoZSBzdGF0dXMgb2YgdGhpcyBjZXJ0aWZpY2F0 ZSZxdW90Oy4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+OjwvZm9udD48Zm9udCBz aXplPTQgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPlJ1c3M8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcGtpeCBtYWlsaW5nIGxpc3Q8YnI+ DQpwa2l4QGlldGYub3JnPGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXg+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXg8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNp emU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 005F2E5EC1257A67_=-- From turners@ieca.com Tue Aug 28 08:33:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3A321F84B2 for ; Tue, 28 Aug 2012 08:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.056 X-Spam-Level: X-Spam-Status: No, score=-102.056 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJrlrEDmIWst for ; Tue, 28 Aug 2012 08:33:49 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.41.248.83]) by ietfa.amsl.com (Postfix) with ESMTP id 53C3621F854F for ; Tue, 28 Aug 2012 08:33:49 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id D9687FDC6690E; Tue, 28 Aug 2012 10:33:46 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id CD439FDC668C0 for ; Tue, 28 Aug 2012 10:33:46 -0500 (CDT) Received: from [108.18.174.220] (port=63364 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1T6NnV-00037r-Nr; Tue, 28 Aug 2012 10:33:45 -0500 Message-ID: <503CE4D9.2020006@ieca.com> Date: Tue, 28 Aug 2012 11:33:45 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: denis.pinkas@bull.net References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> <65DA4BEA501AFC409DF274CC71ED01A53A551F2B@SOTTEXCH10.corp.ad.entrust.com> <4918BCF9-2556-4E9F-9398-2222E62D7E14@vigilsec.com> <65DA4BEA501AFC409DF274CC71ED01A53A551FA6@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:63364 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:33:50 -0000 Denis, PKIX supports the 1st part (partitioned & delta CRLs) of the eg but not the 2nd part (CRL scope extension) so we could we just remove the ", or an entry may represent a range of certificates" from the parenthetical? spt On 8/27/12 1:19 PM, denis.pinkas@bull.net wrote: > Sharon, > > Thank you for the proposal. > > I believe that a simplification would be possible, since we do not > describe all the features of X.509 in RFC 5280: > > a) In the penultimate sentence of the first paragraph of 5.3 > replace “status of any certificate” with “status of this certificate” > b) Add a new second paragraph in 5.3 that states “/Therefore, a > critical extension in the /*/crlEntryExtensions/**//*/field of an entry > shall affect only the certificate specified in that entry, unless there > is a related critical extension in the *crlExtensions*//field > that advertises a special treatment for it.”/ > > Denis > > > > De : Sharon Boeyen > A : Russ Housley > Cc : IETF PKIX > Date : 27/08/2012 19:09 > Objet : Re: [pkix] Errata in section 5.3 from RFC 5280 > Envoyé par : pkix-bounces@ietf.org > ------------------------------------------------------------------------ > > > > I think the easiest way to clarify it would be: > > a) In the penultimate sentence of the first paragraph of 5.3 > replace “status of any certificate” with “status of this certificate” > b) Add a new second paragraph in 5.3 that states “/If an extension > affects the treatment of the list (e.g., multiple CRLs need to be > scanned to examine the entire list of revoked certificates, or an entry > may represent a range of certificates), then either that extension or a > related extension shall be indicated as critical in the > /*/crlExtensions/*/field. Therefore, a critical extension in the > /*/crlEntryExtensions/**//*/field of an entry shall affect only the > certificate specified in that entry, unless there is a related critical > extension in the *crlExtensions*//field that advertises a special > treatment for it.”/ > > *From:* Russ Housley [mailto:housley@vigilsec.com] * > Sent:* Monday, August 27, 2012 12:42 PM* > To:* Sharon Boeyen* > Cc:* IETF PKIX* > Subject:* Re: [pkix] Errata in section 5.3 from RFC 5280 > > Sharon: > > Thanks for digging up those words. They support the position that I > have stated. > > How do you believe the clarifications document should change to express > this point? > > Russ > > > On Aug 27, 2012, at 12:39 PM, Sharon Boeyen wrote: > > > Russ, I realize the RFC 5280 references the 2005 edition of X.509. > However the 2009 edition (freely available > at_http://www.x500standard.com/index.php?n=Ig.LatestAvail_) revises this > text again slightly and I think makes the intent even clearer. It states > (as part of the main text and no longer a note): > > /If an extension affects the treatment of the list (e.g., multiple CRLs > need to be scanned to examine the entire list of revoked certificates, > or an entry may represent a range of certificates), then either that > extension or a related extension shall be indicated as critical in the > /*/crlExtensions/*/field. Therefore, a critical extension in the > /*/crlEntryExtensions/**//*/field of an entry shall affect only the > certificate specified in that entry, unless there is a related critical > extension in the *crlExtensions*//field that advertises a special > treatment for it. The only example of this situation defined in this > Specification is the /*/certificateIssuer/*/CRL entry extension and the > related /*/issuingDistributionPoint/*/CRL extension when the*indirectCRL > *//Boolean from that extension is set to /*/TRUE/*/./ > > > This is clearly the case for certificateIssuer as you indicate below and > as you note below the only other 2 standard crl entry extensions are > irrelevant as they can only ever be non-critical and affect only the > single identified revoked certificate. Any private extension that might > be defined as a crlEntry extension would also have to follow that same > rule to be compliant with the base standard. I do believe the 2005 text > was clear but offer this 2009 as additional confirmation of the intent > (I personally find this text even clearer). > > Cheers, > Sharon > > > *From:* _pkix-bounces@ietf.org_ > _[mailto:pkix-bounces@ietf.org]_ > *On Behalf Of *Russ Housley* > Sent:* Thursday, August 23, 2012 4:15 PM* > To:* Santosh Chokhani* > Cc:* IETF PKIX* > Subject:* Re: [pkix] Errata in section 5.3 from RFC 5280 > > Santosh: > > > RFC 5280 describes three CRL Entry Extensions, and all of them come from > X.509: > > 5.3.1. Reason Code > 5.3.2. Invalidity Date > 5.3.3. Certificate Issuer > > The first two do not have the concern that you describe, and the third > one should only be present if the CRL includes the > IssuingDistributionPoint CRL extension, and that extension includes the > indirectCRL set to TRUE. The IssuingDistributionPoint CRL extension > must be critical. RFC 5280 says: > > The issuing distribution point is a critical CRL extension that > identifies the CRL distribution point and scope for a particular CRL, > and it indicates whether the CRL covers revocation for end entity > certificates only, CA certificates only, attribute certificates only, > or a limited set of reason codes. Although the extension is > critical, conforming implementations are not required to support this > extension. However, implementations that do not support this > extension MUST either treat the status of any certificate not listed > on this CRL as unknown or locate another CRL that does not contain > any unrecognized critical extensions. > > To my mind, the support for the critical IssuingDistributionPoint CRL > extension includes the proper support for the Certificate Issuer CRL > entry extension. > > Russ > > > On Aug 23, 2012, at 4:01 PM, Santosh Chokhani wrote: > > > > Russ, > > The problem with Denis’s proposal is that he wants to replace the text > of not using the CRL. > > I have cited a specific example in 5280 itself where an entry extension > scope goes beyond that of the entry. It potentially impacts subsequent > entries. > > Thus, Denis’s proposal is unacceptable. If he just wanted to add the > sentence as opposed to replace, it would be fine. > > In general, unless 5280 and X.509 stated that an entry extension cannot > impact semantics of anything in the CRL other than the entry itself, > what you say is unacceptable and potentially insecure. > > *From:* _pkix-bounces@ietf.org_ > _[mailto:pkix-bounces@ietf.org]_ > *On Behalf Of *Russ Housley* > Sent:* Thursday, August 23, 2012 3:50 PM* > To:* _denis.pinkas@bull.net_ * > Cc:* IETF PKIX* > Subject:* Re: [pkix] Errata in section 5.3 from RFC 5280 > > > I agree with the proposal that Denis makes. I support his proposed text. > > This validates my text proposal which still is: > > If a CRL contains a critical CRL entry extension that the application > cannot process, then the application MUST NOT use that CRL entry to > determine the status of this certificate". : > > Russ > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From internet-drafts@ietf.org Tue Aug 28 09:18:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B21A21F84E4; Tue, 28 Aug 2012 09:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Zj36W7o8-EN; Tue, 28 Aug 2012 09:18:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D9B21F84F3; Tue, 28 Aug 2012 09:18:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120828161824.12779.10639.idtracker@ietfa.amsl.com> Date: Tue, 28 Aug 2012 09:18:24 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-caa-13.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:18:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource= Record Author(s) : Phillip Hallam-Baker Rob Stradling Filename : draft-ietf-pkix-caa-13.txt Pages : 18 Date : 2012-08-28 Abstract: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-caa There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-caa-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-caa-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From denis.pinkas@bull.net Tue Aug 28 09:19:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81D221F84F7 for ; Tue, 28 Aug 2012 09:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCEs4fxQ2thG for ; Tue, 28 Aug 2012 09:19:05 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE1421F84F3 for ; Tue, 28 Aug 2012 09:19:05 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id A4E24180ED for ; Tue, 28 Aug 2012 18:19:04 +0200 (CEST) To: pkix@ietf.org MIME-Version: 1.0 X-KeepSent: 1B1D0C4F:C078849E-C1257A5F:0028448F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Tue, 28 Aug 2012 18:19:04 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 28/08/2012 18:19:04, Serialize complete at 28/08/2012 18:19:04 Content-Type: multipart/alternative; boundary="=_alternative 00592A4DC1257A68_=" Subject: [pkix] draft-pinkas-rfc2560bis-00 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:19:06 -0000 Message en plusieurs parties au format MIME --=_alternative 00592A4DC1257A68_= Content-Type: text/plain; charset="US-ASCII" A new Internet-Draft is available from the on-line Internet-Drafts directories. Title : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Author(s) : D. Pinkas Filename : draft-pinkas-rfc2560bis Pages : 41 Date : Aug. 27, 2012 This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFC 2560 and RFC 6277. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. A few explanations about the content of draft-ietf-pinkas-rfc2560bis-00. 25 changes are indicated at the beginning of the document. I will only mention a few of them: A - Explanations were missing to describe: - the building of a request by an OCSP client, - the processing of a request by an OCSP server, - the building of a response by an OCSP server, and - the processing of a response by an OCSP client. These explanations have been added. B - Explanations were missing to address CA key rollover and OCSP key rollover. These explanations have been added. C - Backwards compatibility has been addressed in the following way: 1) An OCSP response by be signed either by a CA or by an OCSP Responder. 2) Besides local configuration settings which are optional, only two cases SHALL be supported by OCSP clients (and thus OCSP servers) as explained below. The key to be used to verify a SingleResponse (within a BasicOCSPResponse) MUST: (1) either be the same key that the one used to sign the target certificate, (2) or be the public key from an OCSP responder that is contained in an OCSP certificate that has been signed by the same key that the one used to sign the target certificate. . The text allows to use the same general processing for a few other cases, since "escape" sentences are provided to allow for these other cases, but only using "local configuration settings". This means in particular that the Identrust model may be supported and that the "several many cases" that were detailed in the annexes from draft -04 from David Cooper and Stefan Santesson (but which were not interoperable with most current implementations) can take benefit of the description of the general processing. Denis --=_alternative 00592A4DC1257A68_= Content-Type: text/html; charset="US-ASCII" A new Internet-Draft is available from the on-line Internet-Drafts directories.

   Title         : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
   Author(s)     : D. Pinkas
   Filename      : draft-pinkas-rfc2560bis
   Pages         : 41
   Date          : Aug. 27, 2012
   
  This document specifies a protocol useful in determining the current
  status of a digital certificate without requiring CRLs.  Additional
  mechanisms addressing PKIX operational requirements are specified in
  separate documents. This document obsoletes RFC 2560 and RFC 6277.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation
to automatically retrieve the ASCII version of the Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bis>

A few explanations about the content of draft-ietf-pinkas-rfc2560bis-00.

25 changes are indicated at the beginning of the document.
I will only mention a few of them:

A - Explanations were missing to describe:

     - the building of a request by an OCSP client,
     - the processing of a request by an OCSP server,
     - the building of a response  by an OCSP server, and
     - the processing of a response by an OCSP client.

These explanations have been added.

B - Explanations were missing to  address CA key rollover and OCSP key rollover.
     These explanations have been added.

C - Backwards compatibility has been addressed in the following way:

      1) An OCSP response by be signed either by a CA or by an OCSP Responder.

      2) Besides local configuration settings which are optional, only two cases
       SHALL be supported by OCSP clients (and thus OCSP servers) as explained below.

       The key to be used to verify a SingleResponse (within a BasicOCSPResponse) MUST:

          (1) either be the same key that the one used to sign the target certificate,
          (2) or be the public key from an OCSP responder that is contained in an OCSP certificate
              that has been signed by the same key that the one used to sign the target certificate.
   .
The text allows to use the same general processing for a few other cases, since "escape"
sentences are provided to allow for these other cases, but only using "local configuration settings".

This means in particular that the Identrust model may be supported and that the "several many cases"
that were detailed in the annexes from draft -04 from David Cooper and Stefan Santesson
(but which were not interoperable with most current implementations) can take benefit of the description
of the general processing.

Denis
--=_alternative 00592A4DC1257A68_=-- From SChokhani@cygnacom.com Tue Aug 28 10:45:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0B821F85B8 for ; Tue, 28 Aug 2012 10:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aiXvO-khNQR for ; Tue, 28 Aug 2012 10:45:21 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 79AB921F85AC for ; Tue, 28 Aug 2012 10:45:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,327,1344225600"; d="scan'208,217";a="1806359" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 28 Aug 2012 13:45:16 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 28 Aug 2012 13:45:15 -0400 From: Santosh Chokhani To: "denis.pinkas@bull.net" , Sharon Boeyen Date: Tue, 28 Aug 2012 13:45:14 -0400 Thread-Topic: [pkix] Errata in section 5.3 from RFC 5280 Thread-Index: Ac2EeC3T0QO8evaQRBim7Eewwvwc0AAy0Cvg Message-ID: References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> <65DA4BEA501AFC409DF274CC71ED01A53A551F2B@SOTTEXCH10.corp.ad.entrust.com> <4918BCF9-2556-4E9F-9398-2222E62D7E14@vigilsec.com> <65DA4BEA501AFC409DF274CC71ED01A53A551FA6@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF362EC493scygexch7cygnac_" MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:45:22 -0000 --_000_B83745DA469B7847811819C5005244AF362EC493scygexch7cygnac_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVuaXMgYW5kIFNoYXJvbiwNCg0KSSB3b3VsZCBwcm9wb3NlIHRoZSBmb2xsb3dpbmc6DQoNCg0K YSkgICAgICBJbiB0aGUgcGVudWx0aW1hdGUgc2VudGVuY2Ugb2YgdGhlIGZpcnN0IHBhcmFncmFw aCBvZiA1LjMgcmVwbGFjZSDigJxzdGF0dXMgb2YgYW55IGNlcnRpZmljYXRl4oCdIHdpdGgg4oCc c3RhdHVzIG9mIHRoZSBjZXJ0aWZpY2F0ZSByZXByZXNlbnRlZCBieSB0aGUgQ1JMIGVudHJ54oCd Lg0KDQoNCmIpICAgICAgQSBjcml0aWNhbCBleHRlbnNpb24gaW4gdGhlIGNybEVudHJ5RXh0ZW5z aW9ucyBmaWVsZCBvZiBhbiBlbnRyeSBzaGFsbCBhZmZlY3Qgb25seSB0aGUgY2VydGlmaWNhdGUg c3BlY2lmaWVkIGluIHRoYXQgZW50cnksIHVubGVzcyB0aGVyZSBpcyBhIHJlbGF0ZWQgY3JpdGlj YWwgZXh0ZW5zaW9uIGluIHRoZSBjcmxFeHRlbnNpb25zIGZpZWxkIHRoYXQgYWR2ZXJ0aXNlcyBh IHNwZWNpYWwgdHJlYXRtZW50IGZvciBpdC7igJ0gIEluIG9yZGVyIHRvIHVzZSBzdWNoIENSTCwg dGhlIHJlbHlpbmcgcGFydHkgbXVzdCBiZSBhYmxlIHRvIHByb2Nlc3MgYm90aCB0aGUgY3JsRW50 cnlFeHRlbnNpb24gYW5kIHRoZSByZWxhdGVkIGNybEV4dGVuc2lvbi4NCg0KRnJvbTogcGtpeC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgZGVuaXMucGlua2FzQGJ1bGwubmV0DQpTZW50OiBNb25kYXksIEF1Z3VzdCAyNywgMjAxMiAx OjIwIFBNDQpUbzogU2hhcm9uIEJvZXllbg0KQ2M6IElFVEYgUEtJWA0KU3ViamVjdDogUmU6IFtw a2l4XSBFcnJhdGEgaW4gc2VjdGlvbiA1LjMgZnJvbSBSRkMgNTI4MA0KDQpTaGFyb24sDQoNClRo YW5rIHlvdSBmb3IgdGhlIHByb3Bvc2FsLg0KDQpJIGJlbGlldmUgdGhhdCBhIHNpbXBsaWZpY2F0 aW9uIHdvdWxkIGJlIHBvc3NpYmxlLCBzaW5jZSB3ZSBkbyBub3QgZGVzY3JpYmUgYWxsIHRoZSBm ZWF0dXJlcyBvZiAgWC41MDkgaW4gUkZDIDUyODA6DQoNCmEpICAgICAgSW4gdGhlIHBlbnVsdGlt YXRlIHNlbnRlbmNlIG9mIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgNS4zIHJlcGxhY2Ug4oCcc3Rh dHVzIG9mIGFueSBjZXJ0aWZpY2F0ZeKAnSB3aXRoIOKAnHN0YXR1cyBvZiB0aGlzIGNlcnRpZmlj YXRl4oCdDQpiKSAgICAgIEFkZCBhIG5ldyBzZWNvbmQgcGFyYWdyYXBoIGluIDUuMyB0aGF0IHN0 YXRlcyDigJxUaGVyZWZvcmUsIGEgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSBjcmxFbnRyeUV4 dGVuc2lvbnMgZmllbGQgb2YgYW4gZW50cnkNCnNoYWxsIGFmZmVjdCBvbmx5IHRoZSBjZXJ0aWZp Y2F0ZSBzcGVjaWZpZWQgaW4gdGhhdCBlbnRyeSwgdW5sZXNzIHRoZXJlIGlzIGEgcmVsYXRlZCBj cml0aWNhbCBleHRlbnNpb24gaW4gdGhlIGNybEV4dGVuc2lvbnMgZmllbGQNCnRoYXQgYWR2ZXJ0 aXNlcyBhIHNwZWNpYWwgdHJlYXRtZW50IGZvciBpdC7igJ0NCg0KRGVuaXMNCg0KDQoNCkRlIDog ICAgICAgIFNoYXJvbiBCb2V5ZW4gPHNoYXJvbi5ib2V5ZW5AZW50cnVzdC5jb208bWFpbHRvOnNo YXJvbi5ib2V5ZW5AZW50cnVzdC5jb20+Pg0KQSA6ICAgICAgICBSdXNzIEhvdXNsZXkgPGhvdXNs ZXlAdmlnaWxzZWMuY29tPG1haWx0bzpob3VzbGV5QHZpZ2lsc2VjLmNvbT4+DQpDYyA6ICAgICAg ICBJRVRGIFBLSVggPHBraXhAaWV0Zi5vcmc8bWFpbHRvOnBraXhAaWV0Zi5vcmc+Pg0KRGF0ZSA6 ICAgICAgICAyNy8wOC8yMDEyIDE5OjA5DQpPYmpldCA6ICAgICAgICBSZTogW3BraXhdIEVycmF0 YSBpbiBzZWN0aW9uIDUuMyBmcm9tIFJGQyA1MjgwDQpFbnZvecOpIHBhciA6ICAgICAgICBwa2l4 LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZz4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpJIHRoaW5rIHRoZSBlYXNpZXN0IHdheSB0 byBjbGFyaWZ5IGl0IHdvdWxkIGJlOg0KDQphKSAgICAgIEluIHRoZSBwZW51bHRpbWF0ZSBzZW50 ZW5jZSBvZiB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIDUuMyByZXBsYWNlIOKAnHN0YXR1cyBvZiBh bnkgY2VydGlmaWNhdGXigJ0gd2l0aCDigJxzdGF0dXMgb2YgdGhpcyBjZXJ0aWZpY2F0ZeKAnQ0K YikgICAgICBBZGQgYSBuZXcgc2Vjb25kIHBhcmFncmFwaCBpbiA1LjMgdGhhdCBzdGF0ZXMg4oCc SWYgYW4gZXh0ZW5zaW9uIGFmZmVjdHMgdGhlIHRyZWF0bWVudCBvZiB0aGUgbGlzdCAoZS5nLiwg bXVsdGlwbGUgQ1JMcyBuZWVkIHRvIGJlIHNjYW5uZWQgdG8gZXhhbWluZSB0aGUgZW50aXJlIGxp c3Qgb2YgcmV2b2tlZCBjZXJ0aWZpY2F0ZXMsIG9yIGFuIGVudHJ5IG1heSByZXByZXNlbnQgYSBy YW5nZSBvZiBjZXJ0aWZpY2F0ZXMpLCB0aGVuIGVpdGhlciB0aGF0IGV4dGVuc2lvbiBvciBhIHJl bGF0ZWQgZXh0ZW5zaW9uIHNoYWxsIGJlIGluZGljYXRlZCBhcyBjcml0aWNhbCBpbiB0aGUgY3Js RXh0ZW5zaW9uc2ZpZWxkLiBUaGVyZWZvcmUsIGEgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSBj cmxFbnRyeUV4dGVuc2lvbnMgZmllbGQgb2YgYW4gZW50cnkgc2hhbGwgYWZmZWN0IG9ubHkgdGhl IGNlcnRpZmljYXRlIHNwZWNpZmllZCBpbiB0aGF0IGVudHJ5LCB1bmxlc3MgdGhlcmUgaXMgYSBy ZWxhdGVkIGNyaXRpY2FsIGV4dGVuc2lvbiBpbiB0aGUgY3JsRXh0ZW5zaW9ucyBmaWVsZCB0aGF0 IGFkdmVydGlzZXMgYSBzcGVjaWFsIHRyZWF0bWVudCBmb3IgaXQu4oCdDQoNCkZyb206IFJ1c3Mg SG91c2xleSBbbWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tXQ0KU2VudDogTW9uZGF5LCBBdWd1 c3QgMjcsIDIwMTIgMTI6NDIgUE0NClRvOiBTaGFyb24gQm9leWVuDQpDYzogSUVURiBQS0lYDQpT dWJqZWN0OiBSZTogW3BraXhdIEVycmF0YSBpbiBzZWN0aW9uIDUuMyBmcm9tIFJGQyA1MjgwDQoN ClNoYXJvbjoNCg0KVGhhbmtzIGZvciBkaWdnaW5nIHVwIHRob3NlIHdvcmRzLiAgVGhleSBzdXBw b3J0IHRoZSBwb3NpdGlvbiB0aGF0IEkgaGF2ZSBzdGF0ZWQuDQoNCkhvdyBkbyB5b3UgYmVsaWV2 ZSB0aGUgY2xhcmlmaWNhdGlvbnMgZG9jdW1lbnQgc2hvdWxkIGNoYW5nZSB0byBleHByZXNzIHRo aXMgcG9pbnQ/DQoNClJ1c3MNCg0KDQpPbiBBdWcgMjcsIDIwMTIsIGF0IDEyOjM5IFBNLCBTaGFy b24gQm9leWVuIHdyb3RlOg0KDQoNClJ1c3MsIEkgcmVhbGl6ZSB0aGUgUkZDIDUyODAgcmVmZXJl bmNlcyB0aGUgMjAwNSBlZGl0aW9uIG9mIFguNTA5LiBIb3dldmVyIHRoZSAyMDA5IGVkaXRpb24g KGZyZWVseSBhdmFpbGFibGUgYXRodHRwOi8vd3d3Lng1MDBzdGFuZGFyZC5jb20vaW5kZXgucGhw P249SWcuTGF0ZXN0QXZhaWwgKSByZXZpc2VzIHRoaXMgdGV4dCBhZ2FpbiBzbGlnaHRseSBhbmQg SSB0aGluayBtYWtlcyB0aGUgaW50ZW50IGV2ZW4gY2xlYXJlci4gSXQgc3RhdGVzIChhcyBwYXJ0 IG9mIHRoZSBtYWluIHRleHQgYW5kIG5vIGxvbmdlciBhIG5vdGUpOg0KDQpJZiBhbiBleHRlbnNp b24gYWZmZWN0cyB0aGUgdHJlYXRtZW50IG9mIHRoZSBsaXN0IChlLmcuLCBtdWx0aXBsZSBDUkxz IG5lZWQgdG8gYmUgc2Nhbm5lZCB0byBleGFtaW5lIHRoZSBlbnRpcmUgbGlzdCBvZiByZXZva2Vk IGNlcnRpZmljYXRlcywgb3IgYW4gZW50cnkgbWF5IHJlcHJlc2VudCBhIHJhbmdlIG9mIGNlcnRp ZmljYXRlcyksIHRoZW4gZWl0aGVyIHRoYXQgZXh0ZW5zaW9uIG9yIGEgcmVsYXRlZCBleHRlbnNp b24gc2hhbGwgYmUgaW5kaWNhdGVkIGFzIGNyaXRpY2FsIGluIHRoZSBjcmxFeHRlbnNpb25zZmll bGQuIFRoZXJlZm9yZSwgYSBjcml0aWNhbCBleHRlbnNpb24gaW4gdGhlIGNybEVudHJ5RXh0ZW5z aW9ucyBmaWVsZCBvZiBhbiBlbnRyeSBzaGFsbCBhZmZlY3Qgb25seSB0aGUgY2VydGlmaWNhdGUg c3BlY2lmaWVkIGluIHRoYXQgZW50cnksIHVubGVzcyB0aGVyZSBpcyBhIHJlbGF0ZWQgY3JpdGlj YWwgZXh0ZW5zaW9uIGluIHRoZSBjcmxFeHRlbnNpb25zIGZpZWxkIHRoYXQgYWR2ZXJ0aXNlcyBh IHNwZWNpYWwgdHJlYXRtZW50IGZvciBpdC4gVGhlIG9ubHkgZXhhbXBsZSBvZiB0aGlzIHNpdHVh dGlvbiBkZWZpbmVkIGluIHRoaXMgU3BlY2lmaWNhdGlvbiBpcyB0aGUgY2VydGlmaWNhdGVJc3N1 ZXIgQ1JMIGVudHJ5IGV4dGVuc2lvbiBhbmQgdGhlIHJlbGF0ZWQgaXNzdWluZ0Rpc3RyaWJ1dGlv blBvaW50IENSTCBleHRlbnNpb24gd2hlbiB0aGVpbmRpcmVjdENSTCBCb29sZWFuIGZyb20gdGhh dCBleHRlbnNpb24gaXMgc2V0IHRvIFRSVUUuDQoNCg0KVGhpcyBpcyBjbGVhcmx5IHRoZSBjYXNl IGZvciBjZXJ0aWZpY2F0ZUlzc3VlciBhcyB5b3UgaW5kaWNhdGUgYmVsb3cgYW5kIGFzIHlvdSBu b3RlIGJlbG93IHRoZSBvbmx5IG90aGVyIDIgc3RhbmRhcmQgY3JsIGVudHJ5IGV4dGVuc2lvbnMg YXJlIGlycmVsZXZhbnQgYXMgdGhleSBjYW4gb25seSBldmVyIGJlIG5vbi1jcml0aWNhbCBhbmQg YWZmZWN0IG9ubHkgdGhlIHNpbmdsZSBpZGVudGlmaWVkIHJldm9rZWQgY2VydGlmaWNhdGUuIEFu eSBwcml2YXRlIGV4dGVuc2lvbiB0aGF0IG1pZ2h0IGJlIGRlZmluZWQgYXMgYSBjcmxFbnRyeSBl eHRlbnNpb24gd291bGQgYWxzbyBoYXZlIHRvIGZvbGxvdyB0aGF0IHNhbWUgcnVsZSB0byBiZSBj b21wbGlhbnQgd2l0aCB0aGUgYmFzZSBzdGFuZGFyZC4gSSBkbyBiZWxpZXZlIHRoZSAyMDA1IHRl eHQgd2FzIGNsZWFyIGJ1dCBvZmZlciB0aGlzIDIwMDkgYXMgYWRkaXRpb25hbCBjb25maXJtYXRp b24gb2YgdGhlIGludGVudCAoSSBwZXJzb25hbGx5IGZpbmQgdGhpcyB0ZXh0IGV2ZW4gY2xlYXJl cikuDQoNCkNoZWVycywNClNoYXJvbg0KDQoNCkZyb206IHBraXgtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9y Z108bWFpbHRvOlttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVoYWxmIE9mIFJ1 c3MgSG91c2xleQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyMywgMjAxMiA0OjE1IFBNDQpUbzog U2FudG9zaCBDaG9raGFuaQ0KQ2M6IElFVEYgUEtJWA0KU3ViamVjdDogUmU6IFtwa2l4XSBFcnJh dGEgaW4gc2VjdGlvbiA1LjMgZnJvbSBSRkMgNTI4MA0KDQpTYW50b3NoOg0KDQoNClJGQyA1Mjgw IGRlc2NyaWJlcyB0aHJlZSBDUkwgRW50cnkgRXh0ZW5zaW9ucywgYW5kIGFsbCBvZiB0aGVtIGNv bWUgZnJvbSBYLjUwOToNCg0KICAgICAgICAgICAgNS4zLjEuICBSZWFzb24gQ29kZQ0KICAgICAg ICAgICAgNS4zLjIuICBJbnZhbGlkaXR5IERhdGUNCiAgICAgICAgICAgIDUuMy4zLiAgQ2VydGlm aWNhdGUgSXNzdWVyDQoNClRoZSBmaXJzdCB0d28gZG8gbm90IGhhdmUgdGhlIGNvbmNlcm4gdGhh dCB5b3UgZGVzY3JpYmUsIGFuZCB0aGUgdGhpcmQgb25lIHNob3VsZCBvbmx5IGJlIHByZXNlbnQg aWYgdGhlIENSTCBpbmNsdWRlcyB0aGUgSXNzdWluZ0Rpc3RyaWJ1dGlvblBvaW50IENSTCBleHRl bnNpb24sIGFuZCB0aGF0IGV4dGVuc2lvbiBpbmNsdWRlcyB0aGUgaW5kaXJlY3RDUkwgc2V0IHRv IFRSVUUuICBUaGUgSXNzdWluZ0Rpc3RyaWJ1dGlvblBvaW50IENSTCBleHRlbnNpb24gbXVzdCBi ZSBjcml0aWNhbC4gIFJGQyA1MjgwIHNheXM6DQoNCiAgIFRoZSBpc3N1aW5nIGRpc3RyaWJ1dGlv biBwb2ludCBpcyBhIGNyaXRpY2FsIENSTCBleHRlbnNpb24gdGhhdA0KICAgaWRlbnRpZmllcyB0 aGUgQ1JMIGRpc3RyaWJ1dGlvbiBwb2ludCBhbmQgc2NvcGUgZm9yIGEgcGFydGljdWxhciBDUkws DQogICBhbmQgaXQgaW5kaWNhdGVzIHdoZXRoZXIgdGhlIENSTCBjb3ZlcnMgcmV2b2NhdGlvbiBm b3IgZW5kIGVudGl0eQ0KICAgY2VydGlmaWNhdGVzIG9ubHksIENBIGNlcnRpZmljYXRlcyBvbmx5 LCBhdHRyaWJ1dGUgY2VydGlmaWNhdGVzIG9ubHksDQogICBvciBhIGxpbWl0ZWQgc2V0IG9mIHJl YXNvbiBjb2Rlcy4gIEFsdGhvdWdoIHRoZSBleHRlbnNpb24gaXMNCiAgIGNyaXRpY2FsLCBjb25m b3JtaW5nIGltcGxlbWVudGF0aW9ucyBhcmUgbm90IHJlcXVpcmVkIHRvIHN1cHBvcnQgdGhpcw0K ICAgZXh0ZW5zaW9uLiAgSG93ZXZlciwgaW1wbGVtZW50YXRpb25zIHRoYXQgZG8gbm90IHN1cHBv cnQgdGhpcw0KICAgZXh0ZW5zaW9uIE1VU1QgZWl0aGVyIHRyZWF0IHRoZSBzdGF0dXMgb2YgYW55 IGNlcnRpZmljYXRlIG5vdCBsaXN0ZWQNCiAgIG9uIHRoaXMgQ1JMIGFzIHVua25vd24gb3IgbG9j YXRlIGFub3RoZXIgQ1JMIHRoYXQgZG9lcyBub3QgY29udGFpbg0KICAgYW55IHVucmVjb2duaXpl ZCBjcml0aWNhbCBleHRlbnNpb25zLg0KDQpUbyBteSBtaW5kLCB0aGUgc3VwcG9ydCBmb3IgdGhl IGNyaXRpY2FsIElzc3VpbmdEaXN0cmlidXRpb25Qb2ludCBDUkwgZXh0ZW5zaW9uIGluY2x1ZGVz IHRoZSBwcm9wZXIgc3VwcG9ydCBmb3IgdGhlIENlcnRpZmljYXRlIElzc3VlciBDUkwgZW50cnkg ZXh0ZW5zaW9uLg0KDQpSdXNzDQoNCg0KT24gQXVnIDIzLCAyMDEyLCBhdCA0OjAxIFBNLCBTYW50 b3NoIENob2toYW5pIHdyb3RlOg0KDQoNCg0KUnVzcywNCg0KVGhlIHByb2JsZW0gd2l0aCBEZW5p c+KAmXMgcHJvcG9zYWwgaXMgdGhhdCBoZSB3YW50cyB0byByZXBsYWNlIHRoZSB0ZXh0IG9mIG5v dCB1c2luZyB0aGUgQ1JMLg0KDQpJIGhhdmUgY2l0ZWQgYSBzcGVjaWZpYyBleGFtcGxlIGluIDUy ODAgaXRzZWxmIHdoZXJlIGFuIGVudHJ5IGV4dGVuc2lvbiBzY29wZSBnb2VzIGJleW9uZCB0aGF0 IG9mIHRoZSBlbnRyeS4gIEl0IHBvdGVudGlhbGx5IGltcGFjdHMgc3Vic2VxdWVudCBlbnRyaWVz Lg0KDQpUaHVzLCBEZW5pc+KAmXMgcHJvcG9zYWwgaXMgdW5hY2NlcHRhYmxlLiAgSWYgaGUganVz dCB3YW50ZWQgdG8gYWRkIHRoZSBzZW50ZW5jZSBhcyBvcHBvc2VkIHRvIHJlcGxhY2UsIGl0IHdv dWxkIGJlIGZpbmUuDQoNCkluIGdlbmVyYWwsIHVubGVzcyA1MjgwIGFuZCBYLjUwOSBzdGF0ZWQg dGhhdCBhbiBlbnRyeSBleHRlbnNpb24gY2Fubm90IGltcGFjdCBzZW1hbnRpY3Mgb2YgYW55dGhp bmcgaW4gdGhlIENSTCBvdGhlciB0aGFuIHRoZSBlbnRyeSBpdHNlbGYsIHdoYXQgeW91IHNheSBp cyB1bmFjY2VwdGFibGUgYW5kIHBvdGVudGlhbGx5IGluc2VjdXJlLg0KDQpGcm9tOiBwa2l4LWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwa2l4 LWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZ10+ IE9uIEJlaGFsZiBPZiBSdXNzIEhvdXNsZXkNClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjMsIDIw MTIgMzo1MCBQTQ0KVG86IGRlbmlzLnBpbmthc0BidWxsLm5ldDxtYWlsdG86ZGVuaXMucGlua2Fz QGJ1bGwubmV0Pg0KQ2M6IElFVEYgUEtJWA0KU3ViamVjdDogUmU6IFtwa2l4XSBFcnJhdGEgaW4g c2VjdGlvbiA1LjMgZnJvbSBSRkMgNTI4MA0KDQoNCkkgYWdyZWUgd2l0aCB0aGUgcHJvcG9zYWwg dGhhdCBEZW5pcyBtYWtlcy4gIEkgc3VwcG9ydCBoaXMgcHJvcG9zZWQgdGV4dC4NCg0KVGhpcyB2 YWxpZGF0ZXMgbXkgdGV4dCBwcm9wb3NhbCB3aGljaCBzdGlsbCBpczoNCg0KICBJZiBhIENSTCBj b250YWlucyBhIGNyaXRpY2FsIENSTCBlbnRyeSBleHRlbnNpb24gdGhhdCB0aGUgYXBwbGljYXRp b24NCiBjYW5ub3QgcHJvY2VzcywgdGhlbiB0aGUgYXBwbGljYXRpb24gTVVTVCBOT1QgdXNlIHRo YXQgQ1JMIGVudHJ5IHRvDQogZGV0ZXJtaW5lIHRoZSBzdGF0dXMgb2YgdGhpcyBjZXJ0aWZpY2F0 ZSIuIDoNCg0KUnVzcw0KDQogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnBraXggbWFpbGluZyBsaXN0DQpwa2l4QGlldGYub3JnPG1haWx0bzpwa2l4QGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wa2l4DQo= --_000_B83745DA469B7847811819C5005244AF362EC493scygexch7cygnac_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnR0DQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3Jh dGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTAzMzU3NDgzNzsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTc2NDYxMTczMCAx NDIzMDc0MjMwIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjM5LjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVy cGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkRlbmlzIGFuZCBTaGFyb24sPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIHdvdWxkIHByb3Bvc2Ug dGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjM5LjBwdDt0ZXh0LWluZGVudDotMjEu MHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiMwMDQwODAnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmEpPHNwYW4gc3R5bGU9 J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5J biB0aGUgcGVudWx0aW1hdGUgc2VudGVuY2Ugb2YgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiA1LjMg cmVwbGFjZSDigJxzdGF0dXMgb2YgYW55IGNlcnRpZmljYXRl4oCdIHdpdGgg4oCcc3RhdHVzIG9m IHRoZSBjZXJ0aWZpY2F0ZSByZXByZXNlbnRlZCBieSB0aGUgQ1JMIGVudHJ54oCdLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0n bWFyZ2luLWxlZnQ6MzkuMHB0O3RleHQtaW5kZW50Oi0yMS4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+Yik8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxMDQxNjAnPkEgY3JpdGljYWwgZXh0ZW5zaW9uIGlu IHRoZSA8Yj5jcmxFbnRyeUV4dGVuc2lvbnM8L2I+IGZpZWxkIG9mIGFuIGVudHJ5IHNoYWxsIGFm ZmVjdCBvbmx5IHRoZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQgaW4gdGhhdCBlbnRyeSwgdW5sZXNz IHRoZXJlIGlzIGEgcmVsYXRlZCBjcml0aWNhbCBleHRlbnNpb24gaW4gdGhlIDxiPmNybEV4dGVu c2lvbnM8L2I+IGZpZWxkIHRoYXQgYWR2ZXJ0aXNlcyBhIHNwZWNpYWwgdHJlYXRtZW50IGZvciBp dC7igJ3CoCBJbiBvcmRlciB0byB1c2Ugc3VjaCBDUkwsIHRoZSByZWx5aW5nIHBhcnR5IG11c3Qg YmUgYWJsZSB0byBwcm9jZXNzIGJvdGggdGhlIDxiPmNybEVudHJ5RXh0ZW5zaW9uIDwvYj5hbmQg dGhlIHJlbGF0ZWQgPGI+Y3JsRXh0ZW5zaW9uLjwvYj4gPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gcGtpeC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPmRlbmlzLnBp bmthc0BidWxsLm5ldDxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgMjcsIDIwMTIgMToy MCBQTTxicj48Yj5Ubzo8L2I+IFNoYXJvbiBCb2V5ZW48YnI+PGI+Q2M6PC9iPiBJRVRGIFBLSVg8 YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbcGtpeF0gRXJyYXRhIGluIHNlY3Rpb24gNS4zIGZyb20g UkZDIDUyODA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+U2hhcm9uLDwvc3Bhbj4gPGJy Pjxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIic+VGhhbmsgeW91IGZvciB0aGUgcHJvcG9zYWwuPC9zcGFuPiA8YnI+PGJyPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiJz5JIGJlbGlldmUgdGhhdCBhIHNpbXBsaWZpY2F0aW9uIHdvdWxkIGJlIHBvc3NpYmxlLCBz aW5jZSB3ZSBkbyBub3QgZGVzY3JpYmUgYWxsIHRoZSBmZWF0dXJlcyBvZiAmbmJzcDtYLjUwOSBp biBSRkMgNTI4MDo8L3NwYW4+IDxicj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5hKSAmbmJz cDsgJm5ic3A7ICZuYnNwO0luIHRoZSBwZW51bHRpbWF0ZSBzZW50ZW5jZSBvZiB0aGUgZmlyc3Qg cGFyYWdyYXBoIG9mIDUuMyByZXBsYWNlIOKAnHN0YXR1cyBvZiBhbnkgY2VydGlmaWNhdGXigJ0g d2l0aCDigJxzdGF0dXMgb2YgdGhpcyBjZXJ0aWZpY2F0ZeKAnSA8L3NwYW4+PGJyPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzAwNDA4MCc+YikgJm5ic3A7ICZuYnNwOyAmbmJzcDtBZGQgYSBuZXcgc2Vjb25kIHBh cmFncmFwaCBpbiA1LjMgdGhhdCBzdGF0ZXMg4oCcPC9zcGFuPjxpPjxzcGFuIHN0eWxlPSdjb2xv cjojMTA0MTYwJz5UaGVyZWZvcmUsIGEgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSA8L3NwYW4+ PC9pPjxiPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzEwNDE2MCc+Y3JsRW50cnlFeHRlbnNpb25zPC9zcGFuPjxz cGFuIHN0eWxlPSdjb2xvcjojMTA0MTYwJz4gPC9zcGFuPjwvaT48L2I+PGk+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxMDQxNjAnPmZpZWxkIG9mIGFuIGVudHJ5PGJyPnNoYWxsIGFmZmVjdCBvbmx5IHRo ZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQgaW4gdGhhdCBlbnRyeSwgdW5sZXNzIHRoZXJlIGlzIGEg cmVsYXRlZCBjcml0aWNhbCBleHRlbnNpb24gaW4gdGhlIDxiPmNybEV4dGVuc2lvbnM8L2I+IGZp ZWxkIDxicj50aGF0IGFkdmVydGlzZXMgYSBzcGVjaWFsIHRyZWF0bWVudCBmb3IgaXQu4oCdPC9z cGFuPjwvaT4gPGJyPjxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+RGVuaXM8L3NwYW4+IDxicj48YnI+PGJyPjxicj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiM1RjVGNUYnPkRlIDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiInPlNoYXJvbiBCb2V5ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyb24uYm9leWVuQGVudHJ1 c3QuY29tIj5zaGFyb24uYm9leWVuQGVudHJ1c3QuY29tPC9hPiZndDs8L3NwYW4+IDxicj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiM1RjVGNUYnPkEgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+UnVzcyBIb3VzbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20i PmhvdXNsZXlAdmlnaWxzZWMuY29tPC9hPiZndDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM1RjVG NUYnPkNjJm5ic3A7OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+SUVU RiBQS0lYICZsdDs8YSBocmVmPSJtYWlsdG86cGtpeEBpZXRmLm9yZyI+cGtpeEBpZXRmLm9yZzwv YT4mZ3Q7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNUY1RjVGJz5EYXRlIDogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjI3LzA4LzIwMTIgMTk6MDk8L3NwYW4+IDxicj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiM1RjVGNUYnPk9iamV0IDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPlJlOiBbcGtpeF0gRXJyYXRhIGluIHNlY3Rpb24gNS4zIGZyb20gUkZDIDUyODA8 L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiM1RjVGNUYnPkVudm95w6kgcGFyIDogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxhIGhyZWY9Im1haWx0bzpwa2l4LWJvdW5jZXNA aWV0Zi5vcmciPnBraXgtYm91bmNlc0BpZXRmLm9yZzwvYT48L3NwYW4+IDxvOnA+PC9vOnA+PC9w PjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50 ZXInPjxociBzaXplPTIgd2lkdGg9IjEwMCUiIG5vc2hhZGUgc3R5bGU9J2NvbG9yOiNBQ0E4OTkn IGFsaWduPWNlbnRlcj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz48YnI+PGJyPjxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPkkgdGhpbmsgdGhl IGVhc2llc3Qgd2F5IHRvIGNsYXJpZnkgaXQgd291bGQgYmU6PC9zcGFuPiA8YnI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPmEp ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW4gdGhlIHBlbnVsdGltYXRlIHNlbnRlbmNlIG9mIHRoZSBm aXJzdCBwYXJhZ3JhcGggb2YgNS4zIHJlcGxhY2Ug4oCcc3RhdHVzIG9mIGFueSBjZXJ0aWZpY2F0 ZeKAnSB3aXRoIOKAnHN0YXR1cyBvZiB0aGlzIGNlcnRpZmljYXRl4oCdIDwvc3Bhbj48YnI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMDA0MDgwJz5iKSAmbmJzcDsgJm5ic3A7ICZuYnNwO0FkZCBhIG5ldyBzZWNv bmQgcGFyYWdyYXBoIGluIDUuMyB0aGF0IHN0YXRlcyDigJw8L3NwYW4+PGk+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxMDQxNjAnPklmIGFuIGV4dGVuc2lvbiBhZmZlY3RzIHRoZSB0cmVhdG1lbnQgb2Yg dGhlIGxpc3QgKGUuZy4sIG11bHRpcGxlIENSTHMgbmVlZCB0byBiZSBzY2FubmVkIHRvIGV4YW1p bmUgdGhlIGVudGlyZSBsaXN0IG9mIHJldm9rZWQgY2VydGlmaWNhdGVzLCBvciBhbiBlbnRyeSBt YXkgcmVwcmVzZW50IGEgcmFuZ2Ugb2YgY2VydGlmaWNhdGVzKSwgdGhlbiBlaXRoZXIgdGhhdCBl eHRlbnNpb24gb3IgYSByZWxhdGVkIGV4dGVuc2lvbiBzaGFsbCBiZSBpbmRpY2F0ZWQgYXMgY3Jp dGljYWwgaW4gdGhlIDwvc3Bhbj48L2k+PGI+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMTA0MTYwJz5jcmxFeHRl bnNpb25zPC9zcGFuPjwvaT48L2I+PGk+PHNwYW4gc3R5bGU9J2NvbG9yOiMxMDQxNjAnPmZpZWxk LiBUaGVyZWZvcmUsIGEgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSA8L3NwYW4+PC9pPjxiPjxp PjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzEwNDE2MCc+Y3JsRW50cnlFeHRlbnNpb25zPC9zcGFuPjxzcGFuIHN0eWxl PSdjb2xvcjojMTA0MTYwJz4gPC9zcGFuPjwvaT48L2I+PGk+PHNwYW4gc3R5bGU9J2NvbG9yOiMx MDQxNjAnPmZpZWxkIG9mIGFuIGVudHJ5IHNoYWxsIGFmZmVjdCBvbmx5IHRoZSBjZXJ0aWZpY2F0 ZSBzcGVjaWZpZWQgaW4gdGhhdCBlbnRyeSwgdW5sZXNzIHRoZXJlIGlzIGEgcmVsYXRlZCBjcml0 aWNhbCBleHRlbnNpb24gaW4gdGhlIDxiPmNybEV4dGVuc2lvbnM8L2I+IGZpZWxkIHRoYXQgYWR2 ZXJ0aXNlcyBhIHNwZWNpYWwgdHJlYXRtZW50IGZvciBpdC7igJ08L3NwYW4+PC9pPiA8YnI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48Yj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPiBSdXNzIEhvdXNsZXkgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aG91 c2xleUB2aWdpbHNlYy5jb20iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPl0gPGI+PGJyPlNlbnQ6PC9iPiBNb25kYXksIEF1Z3VzdCAyNywgMjAx MiAxMjo0MiBQTTxiPjxicj5Ubzo8L2I+IFNoYXJvbiBCb2V5ZW48Yj48YnI+Q2M6PC9iPiBJRVRG IFBLSVg8Yj48YnI+U3ViamVjdDo8L2I+IFJlOiBbcGtpeF0gRXJyYXRhIGluIHNlY3Rpb24gNS4z IGZyb20gUkZDIDUyODA8L3NwYW4+IDxicj4mbmJzcDsgPGJyPlNoYXJvbjogPGJyPiZuYnNwOyA8 YnI+VGhhbmtzIGZvciBkaWdnaW5nIHVwIHRob3NlIHdvcmRzLiAmbmJzcDtUaGV5IHN1cHBvcnQg dGhlIHBvc2l0aW9uIHRoYXQgSSBoYXZlIHN0YXRlZC4gPGJyPiZuYnNwOyA8YnI+SG93IGRvIHlv dSBiZWxpZXZlIHRoZSBjbGFyaWZpY2F0aW9ucyBkb2N1bWVudCBzaG91bGQgY2hhbmdlIHRvIGV4 cHJlc3MgdGhpcyBwb2ludD8gPGJyPiZuYnNwOyA8YnI+UnVzcyA8YnI+Jm5ic3A7IDxicj4mbmJz cDsgPGJyPk9uIEF1ZyAyNywgMjAxMiwgYXQgMTI6MzkgUE0sIFNoYXJvbiBCb2V5ZW4gd3JvdGU6 IDxicj48YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+UnVzcywgSSByZWFsaXplIHRoZSBS RkMgNTI4MCByZWZlcmVuY2VzIHRoZSAyMDA1IGVkaXRpb24gb2YgWC41MDkuIEhvd2V2ZXIgdGhl IDIwMDkgZWRpdGlvbiAoZnJlZWx5IGF2YWlsYWJsZSBhdDwvc3Bhbj48YSBocmVmPSJodHRwOi8v d3d3Lng1MDBzdGFuZGFyZC5jb20vaW5kZXgucGhwP249SWcuTGF0ZXN0QXZhaWwiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiIn Pmh0dHA6Ly93d3cueDUwMHN0YW5kYXJkLmNvbS9pbmRleC5waHA/bj1JZy5MYXRlc3RBdmFpbDwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz4gKSByZXZpc2VzIHRoaXMgdGV4dCBhZ2Fp biBzbGlnaHRseSBhbmQgSSB0aGluayBtYWtlcyB0aGUgaW50ZW50IGV2ZW4gY2xlYXJlci4gSXQg c3RhdGVzIChhcyBwYXJ0IG9mIHRoZSBtYWluIHRleHQgYW5kIG5vIGxvbmdlciBhIG5vdGUpOjwv c3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8YnI+PGk+PHNw YW4gc3R5bGU9J2NvbG9yOnJlZCc+SWYgYW4gZXh0ZW5zaW9uIGFmZmVjdHMgdGhlIHRyZWF0bWVu dCBvZiB0aGUgbGlzdCAoZS5nLiwgbXVsdGlwbGUgQ1JMcyBuZWVkIHRvIGJlIHNjYW5uZWQgdG8g ZXhhbWluZSB0aGUgZW50aXJlIGxpc3Qgb2YgcmV2b2tlZCBjZXJ0aWZpY2F0ZXMsIG9yIGFuIGVu dHJ5IG1heSByZXByZXNlbnQgYSByYW5nZSBvZiBjZXJ0aWZpY2F0ZXMpLCB0aGVuIGVpdGhlciB0 aGF0IGV4dGVuc2lvbiBvciBhIHJlbGF0ZWQgZXh0ZW5zaW9uIHNoYWxsIGJlIGluZGljYXRlZCBh cyBjcml0aWNhbCBpbiB0aGUgPC9zcGFuPjwvaT48Yj48aT48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOnJlZCc+Y3JsRXh0 ZW5zaW9uczwvc3Bhbj48L2k+PC9iPjxpPjxzcGFuIHN0eWxlPSdjb2xvcjpyZWQnPmZpZWxkLiBU aGVyZWZvcmUsIGEgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSA8L3NwYW4+PC9pPjxiPjxpPjxz cGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6cmVkJz5jcmxFbnRyeUV4dGVuc2lvbnM8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9y OnJlZCc+IDwvc3Bhbj48L2k+PC9iPjxpPjxzcGFuIHN0eWxlPSdjb2xvcjpyZWQnPmZpZWxkIG9m IGFuIGVudHJ5IHNoYWxsIGFmZmVjdCBvbmx5IHRoZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQgaW4g dGhhdCBlbnRyeSwgdW5sZXNzIHRoZXJlIGlzIGEgcmVsYXRlZCBjcml0aWNhbCBleHRlbnNpb24g aW4gdGhlIDxiPmNybEV4dGVuc2lvbnM8L2I+IGZpZWxkIHRoYXQgYWR2ZXJ0aXNlcyBhIHNwZWNp YWwgdHJlYXRtZW50IGZvciBpdC4gVGhlIG9ubHkgZXhhbXBsZSBvZiB0aGlzIHNpdHVhdGlvbiBk ZWZpbmVkIGluIHRoaXMgU3BlY2lmaWNhdGlvbiBpcyB0aGUgPC9zcGFuPjwvaT48Yj48aT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOnJlZCc+Y2VydGlmaWNhdGVJc3N1ZXI8L3NwYW4+PC9pPjwvYj48aT48c3BhbiBzdHls ZT0nY29sb3I6cmVkJz4gQ1JMIGVudHJ5IGV4dGVuc2lvbiBhbmQgdGhlIHJlbGF0ZWQgPC9zcGFu PjwvaT48Yj48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOnJlZCc+aXNzdWluZ0Rpc3RyaWJ1dGlvblBvaW50PC9zcGFu PjwvaT48L2I+PGk+PHNwYW4gc3R5bGU9J2NvbG9yOnJlZCc+IENSTCBleHRlbnNpb24gd2hlbiB0 aGU8Yj5pbmRpcmVjdENSTCA8L2I+Qm9vbGVhbiBmcm9tIHRoYXQgZXh0ZW5zaW9uIGlzIHNldCB0 byA8L3NwYW4+PC9pPjxiPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6cmVkJz5UUlVFPC9zcGFuPjwvaT48L2I+PGk+ PHNwYW4gc3R5bGU9J2NvbG9yOnJlZCc+Ljwvc3Bhbj48L2k+IDxicj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMw MDQwODAnPiZuYnNwOzwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9z cGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5UaGlzIGlzIGNsZWFybHkgdGhlIGNhc2Ug Zm9yIGNlcnRpZmljYXRlSXNzdWVyIGFzIHlvdSBpbmRpY2F0ZSBiZWxvdyBhbmQgYXMgeW91IG5v dGUgYmVsb3cgdGhlIG9ubHkgb3RoZXIgMiBzdGFuZGFyZCBjcmwgZW50cnkgZXh0ZW5zaW9ucyBh cmUgaXJyZWxldmFudCBhcyB0aGV5IGNhbiBvbmx5IGV2ZXIgYmUgbm9uLWNyaXRpY2FsIGFuZCBh ZmZlY3Qgb25seSB0aGUgc2luZ2xlIGlkZW50aWZpZWQgcmV2b2tlZCBjZXJ0aWZpY2F0ZS4gQW55 IHByaXZhdGUgZXh0ZW5zaW9uIHRoYXQgbWlnaHQgYmUgZGVmaW5lZCBhcyBhIGNybEVudHJ5IGV4 dGVuc2lvbiB3b3VsZCBhbHNvIGhhdmUgdG8gZm9sbG93IHRoYXQgc2FtZSBydWxlIHRvIGJlIGNv bXBsaWFudCB3aXRoIHRoZSBiYXNlIHN0YW5kYXJkLiBJIGRvIGJlbGlldmUgdGhlIDIwMDUgdGV4 dCB3YXMgY2xlYXIgYnV0IG9mZmVyIHRoaXMgMjAwOSBhcyBhZGRpdGlvbmFsIGNvbmZpcm1hdGlv biBvZiB0aGUgaW50ZW50IChJIHBlcnNvbmFsbHkgZmluZCB0aGlzIHRleHQgZXZlbiBjbGVhcmVy KS48L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bhbj4gPGJyPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzAwNDA4MCc+Q2hlZXJzLDwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAw NDA4MCc+U2hhcm9uPC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3Nw YW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bhbj4gPGJyPjxiPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Iic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGtpeC1i b3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPnBraXgtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz4gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOnBraXgtYm91bmNlc0BpZXRm Lm9yZ10iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+W21haWx0bzpwa2l4LWJvdW5jZXNAaWV0Zi5vcmddPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPiA8Yj5PbiBCZWhhbGYgT2YgPC9iPlJ1c3MgSG91c2xleTxiPjxicj5TZW50OjwvYj4g VGh1cnNkYXksIEF1Z3VzdCAyMywgMjAxMiA0OjE1IFBNPGI+PGJyPlRvOjwvYj4gU2FudG9zaCBD aG9raGFuaTxiPjxicj5DYzo8L2I+IElFVEYgUEtJWDxiPjxicj5TdWJqZWN0OjwvYj4gUmU6IFtw a2l4XSBFcnJhdGEgaW4gc2VjdGlvbiA1LjMgZnJvbSBSRkMgNTI4MDwvc3Bhbj4gPGJyPiZuYnNw OyA8YnI+U2FudG9zaDogPGJyPiZuYnNwOyA8YnI+Jm5ic3A7IDxicj5SRkMgNTI4MCBkZXNjcmli ZXMgdGhyZWUgQ1JMIEVudHJ5IEV4dGVuc2lvbnMsIGFuZCBhbGwgb2YgdGhlbSBjb21lIGZyb20g WC41MDk6IDxicj4mbmJzcDsgPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDUuMy4xLiAmbmJzcDtSZWFzb24gQ29kZSA8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgNS4zLjIuICZuYnNwO0ludmFsaWRpdHkgRGF0ZSA8YnI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNS4zLjMuICZuYnNwO0NlcnRp ZmljYXRlIElzc3VlciA8YnI+Jm5ic3A7IDxicj5UaGUgZmlyc3QgdHdvIGRvIG5vdCBoYXZlIHRo ZSBjb25jZXJuIHRoYXQgeW91IGRlc2NyaWJlLCBhbmQgdGhlIHRoaXJkIG9uZSBzaG91bGQgb25s eSBiZSBwcmVzZW50IGlmIHRoZSBDUkwgaW5jbHVkZXMgdGhlIElzc3VpbmdEaXN0cmlidXRpb25Q b2ludCBDUkwgZXh0ZW5zaW9uLCBhbmQgdGhhdCBleHRlbnNpb24gaW5jbHVkZXMgdGhlIGluZGly ZWN0Q1JMIHNldCB0byBUUlVFLiAmbmJzcDtUaGUgSXNzdWluZ0Rpc3RyaWJ1dGlvblBvaW50IENS TCBleHRlbnNpb24gbXVzdCBiZSBjcml0aWNhbC4gJm5ic3A7UkZDIDUyODAgc2F5czogPGJyPiZu YnNwOyA8YnI+Jm5ic3A7ICZuYnNwO1RoZSBpc3N1aW5nIGRpc3RyaWJ1dGlvbiBwb2ludCBpcyBh IGNyaXRpY2FsIENSTCBleHRlbnNpb24gdGhhdCA8YnI+Jm5ic3A7ICZuYnNwO2lkZW50aWZpZXMg dGhlIENSTCBkaXN0cmlidXRpb24gcG9pbnQgYW5kIHNjb3BlIGZvciBhIHBhcnRpY3VsYXIgQ1JM LCA8YnI+Jm5ic3A7ICZuYnNwO2FuZCBpdCBpbmRpY2F0ZXMgd2hldGhlciB0aGUgQ1JMIGNvdmVy cyByZXZvY2F0aW9uIGZvciBlbmQgZW50aXR5IDxicj4mbmJzcDsgJm5ic3A7Y2VydGlmaWNhdGVz IG9ubHksIENBIGNlcnRpZmljYXRlcyBvbmx5LCBhdHRyaWJ1dGUgY2VydGlmaWNhdGVzIG9ubHks IDxicj4mbmJzcDsgJm5ic3A7b3IgYSBsaW1pdGVkIHNldCBvZiByZWFzb24gY29kZXMuICZuYnNw O0FsdGhvdWdoIHRoZSBleHRlbnNpb24gaXMgPGJyPiZuYnNwOyAmbmJzcDtjcml0aWNhbCwgY29u Zm9ybWluZyBpbXBsZW1lbnRhdGlvbnMgYXJlIG5vdCByZXF1aXJlZCB0byBzdXBwb3J0IHRoaXMg PGJyPiZuYnNwOyAmbmJzcDtleHRlbnNpb24uICZuYnNwO0hvd2V2ZXIsIGltcGxlbWVudGF0aW9u cyB0aGF0IGRvIG5vdCBzdXBwb3J0IHRoaXMgPGJyPiZuYnNwOyAmbmJzcDtleHRlbnNpb24gTVVT VCBlaXRoZXIgdHJlYXQgdGhlIHN0YXR1cyBvZiBhbnkgY2VydGlmaWNhdGUgbm90IGxpc3RlZCA8 YnI+Jm5ic3A7ICZuYnNwO29uIHRoaXMgQ1JMIGFzIHVua25vd24gb3IgbG9jYXRlIGFub3RoZXIg Q1JMIHRoYXQgZG9lcyBub3QgY29udGFpbiA8YnI+Jm5ic3A7ICZuYnNwO2FueSB1bnJlY29nbml6 ZWQgY3JpdGljYWwgZXh0ZW5zaW9ucy4gPGJyPiZuYnNwOyA8YnI+VG8gbXkgbWluZCwgdGhlIHN1 cHBvcnQgZm9yIHRoZSBjcml0aWNhbCBJc3N1aW5nRGlzdHJpYnV0aW9uUG9pbnQgQ1JMIGV4dGVu c2lvbiBpbmNsdWRlcyB0aGUgcHJvcGVyIHN1cHBvcnQgZm9yIHRoZSBDZXJ0aWZpY2F0ZSBJc3N1 ZXIgQ1JMIGVudHJ5IGV4dGVuc2lvbi4gPGJyPiZuYnNwOyA8YnI+UnVzcyA8YnI+Jm5ic3A7IDxi cj4mbmJzcDsgPGJyPk9uIEF1ZyAyMywgMjAxMiwgYXQgNDowMSBQTSwgU2FudG9zaCBDaG9raGFu aSB3cm90ZTogPGJyPjxicj48YnI+PGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+UnVzcyw8L3NwYW4+ IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAw NDA4MCc+VGhlIHByb2JsZW0gd2l0aCBEZW5pc+KAmXMgcHJvcG9zYWwgaXMgdGhhdCBoZSB3YW50 cyB0byByZXBsYWNlIHRoZSB0ZXh0IG9mIG5vdCB1c2luZyB0aGUgQ1JMLjwvc3Bhbj4gPGJyPjxz cGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA0MDgwJz5J IGhhdmUgY2l0ZWQgYSBzcGVjaWZpYyBleGFtcGxlIGluIDUyODAgaXRzZWxmIHdoZXJlIGFuIGVu dHJ5IGV4dGVuc2lvbiBzY29wZSBnb2VzIGJleW9uZCB0aGF0IG9mIHRoZSBlbnRyeS4gJm5ic3A7 SXQgcG90ZW50aWFsbHkgaW1wYWN0cyBzdWJzZXF1ZW50IGVudHJpZXMuPC9zcGFuPiA8YnI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMDA0MDgwJz4mbmJzcDs8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDQwODAnPlRo dXMsIERlbmlz4oCZcyBwcm9wb3NhbCBpcyB1bmFjY2VwdGFibGUuICZuYnNwO0lmIGhlIGp1c3Qg d2FudGVkIHRvIGFkZCB0aGUgc2VudGVuY2UgYXMgb3Bwb3NlZCB0byByZXBsYWNlLCBpdCB3b3Vs ZCBiZSBmaW5lLjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwNDA4MCc+Jm5ic3A7PC9zcGFuPiA8 YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojMDA0MDgwJz5JbiBnZW5lcmFsLCB1bmxlc3MgNTI4MCBhbmQgWC41MDkg c3RhdGVkIHRoYXQgYW4gZW50cnkgZXh0ZW5zaW9uIGNhbm5vdCBpbXBhY3Qgc2VtYW50aWNzIG9m IGFueXRoaW5nIGluIHRoZSBDUkwgb3RoZXIgdGhhbiB0aGUgZW50cnkgaXRzZWxmLCB3aGF0IHlv dSBzYXkgaXMgdW5hY2NlcHRhYmxlIGFuZCBwb3RlbnRpYWxseSBpbnNlY3VyZS48L3NwYW4+IDxi cj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiMwMDQwODAnPiZuYnNwOzwvc3Bhbj4gPGJyPjxiPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGtpeC1ib3VuY2VzQGll dGYub3JnIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPnBraXgtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4g PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZ10iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+W21haWx0bzpwa2l4LWJvdW5jZXNAaWV0Zi5vcmddPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8 Yj5PbiBCZWhhbGYgT2YgPC9iPlJ1c3MgSG91c2xleTxiPjxicj5TZW50OjwvYj4gVGh1cnNkYXks IEF1Z3VzdCAyMywgMjAxMiAzOjUwIFBNPGI+PGJyPlRvOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpkZW5pcy5waW5rYXNAYnVsbC5uZXQiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ZGVuaXMucGlua2FzQGJ1bGwubmV0 PC9zcGFuPjwvYT48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPjxicj5DYzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IElFVEYgUEtJ WDxiPjxicj5TdWJqZWN0OjwvYj4gUmU6IFtwa2l4XSBFcnJhdGEgaW4gc2VjdGlvbiA1LjMgZnJv bSBSRkMgNTI4MDwvc3Bhbj4gPGJyPiZuYnNwOyA8YnI+Jm5ic3A7IDxicj5JIGFncmVlIHdpdGgg dGhlIHByb3Bvc2FsIHRoYXQgRGVuaXMgbWFrZXMuICZuYnNwO0kgc3VwcG9ydCBoaXMgcHJvcG9z ZWQgdGV4dC4gPGJyPiZuYnNwOyA8YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlRoaXMgdmFsaWRhdGVzIG15IHRleHQgcHJv cG9zYWwgd2hpY2ggc3RpbGwgaXM6PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4gPGJyPjwvc3Bhbj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+Jm5ic3A7 IElmIGEgQ1JMIGNvbnRhaW5zIGEgY3JpdGljYWwgQ1JMIGVudHJ5IGV4dGVuc2lvbiB0aGF0IHRo ZSBhcHBsaWNhdGlvbiA8YnI+Jm5ic3A7Y2Fubm90IHByb2Nlc3MsIHRoZW4gdGhlIGFwcGxpY2F0 aW9uIE1VU1QgTk9UIHVzZSB0aGF0IENSTCBlbnRyeSB0bzxicj4mbmJzcDtkZXRlcm1pbmUgdGhl IHN0YXR1cyBvZiB0aGlzIGNlcnRpZmljYXRlJnF1b3Q7LiA8L3NwYW4+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjo8L3NwYW4+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiInPiA8L3NwYW4+PGJyPiZuYnNwOyA8YnI+UnVzcyA8YnI+Jm5ic3A7IDxicj4mbmJzcDs8 dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPjx0dD5wa2l4IG1haWxpbmcg bGlzdDwvdHQ+PGJyPjx0dD48YSBocmVmPSJtYWlsdG86cGtpeEBpZXRmLm9yZyI+cGtpeEBpZXRm Lm9yZzwvYT48L3R0Pjxicj48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wa2l4Ij48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtpeDwvc3Bhbj48L3R0PjwvYT48 bzpwPjwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_B83745DA469B7847811819C5005244AF362EC493scygexch7cygnac_-- From tgindin@us.ibm.com Thu Aug 30 05:04:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFB421F85B1 for ; Thu, 30 Aug 2012 05:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99zKfbYgIPOm for ; Thu, 30 Aug 2012 05:04:46 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by ietfa.amsl.com (Postfix) with ESMTP id C0E1021F85A8 for ; Thu, 30 Aug 2012 05:04:45 -0700 (PDT) Received: from /spool/local by e1.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 30 Aug 2012 08:04:43 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e1.ny.us.ibm.com (192.168.1.101) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 30 Aug 2012 08:03:28 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 2A6D66E803A for ; Thu, 30 Aug 2012 08:03:27 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7UC39Xj10682616 for ; Thu, 30 Aug 2012 08:03:10 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q7UC2OxH011700 for ; Thu, 30 Aug 2012 08:02:24 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q7UC2OTl011680; Thu, 30 Aug 2012 08:02:24 -0400 In-Reply-To: References: To: Piyush Jain MIME-Version: 1.0 X-KeepSent: 547EE3F4:BF93E67F-85257A69:005DE408; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Thu, 30 Aug 2012 08:02:17 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 08/30/2012 08:02:23, Serialize complete at 08/30/2012 08:02:23 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12083012-6078-0000-0000-00000ED30472 Cc: "pkix@ietf.org" Subject: Re: [pkix] Clarifications in section 4.2 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 12:04:47 -0000 Piyush: I can't speak for Denis, but here's what I see. First, the=20 Extension type is typically used in a SEQUENCE OF or SET OF. Second, the=20 critical flag in the Extension always affects the parent of that SEQUENCE=20 OF or SET OF, but may not radiate beyond that. It often goes higher than=20 that, but whether it goes to the top of the ASN.1 structure in use depends = on the particular structure. For example, invalidating TBSCertificate=20 always invalidates Certificate. At the opposite extreme, a recipient who=20 doesn't recognize a critical extension within one of the certificates in=20 CMS originatorInfo (see RFC 3852 section 6.1) may still build a chain that = doesn't include that certificate. RFC 5280 section 5.3 says that if "a CRL contains a critical CRL=20 entry extension that the application cannot process, then the application=20 MUST NOT use that CRL to determine the status of any certificates". This=20 obviously means that an unrecognized critical entry extension invalidates=20 tbsCertList and CertificateList, not just the individual entry in=20 revokedCertificates. Denis' proposal, although I don't believe that it's required as an = interpretation of the existing standards, boils down to having an=20 unrecognized singleExtension invalidate SingleResponse but not=20 ResponseData. The CRL Entry precedent goes against it, since a natural=20 rule similar to that precedent would be that "for signed structures=20 containing extensions, an unrecognized critical extension renders the=20 innermost signature covering the extension invalid". However, that rule=20 is just a generalization of a few cases which we have, rather than a rule=20 that has been explicitly adopted by anyone. I think Denis' proposal is=20 better for singleExtension anyway. Tom Gindin P.S. - The above opinions are mine, and not necessarily those of my=20 employer From: Piyush Jain To: "denis.pinkas@bull.net" , "pkix@ietf.org"=20 ,=20 Date: 08/27/2012 12:45 PM Subject: Re: [pkix] Clarifications in section 4.2 from RFC 5280 Sent by: pkix-bounces@ietf.org Denis, =20 I think your proposal is based on the assumption that existing text in=20 section 4.1.2.9 applies to ?type? Extensions as opposed to ?instance? of=20 Extensions within structure TBSCertificates. =20 This assumption may not be correct because in later sections 5280 re-=20 defines what Extensions mean in context of a CRL and in context of CRL=20 entry.=20 Your proposal would certainly require changes in 5.1.2.7 and 5.2. =20 Also, your proposed text for Extension imposes restrictions on how other=20 specifications can use this structure. Please see inline for additional=20 comments From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of=20 denis.pinkas@bull.net Sent: Monday, August 27, 2012 12:03 AM To: pkix@ietf.org Subject: [pkix] Clarifications in section 4.2 from RFC 5280 =20 The discussion about the crlEntryExtensions lead me to read again sections = 4.1.2.9=20 and 4.2 from RFC 5280.=20 Section 4.2 has originally been written only in the context of certificate = extensions, whereas=20 extensions are now used by many other RFCs (in particular RFC 2560, which=20 import the Extensions=20 syntax and hence its description).=20 [piyush] The description in 4.2 applies specifically to extensions in=20 context of tbsCertificates. The current text needs to be "clarified".=20 I have reshuffled the text to separate the definition of "extensions",=20 used by RFCs=20 (including RFC 5280 and RFC 2560) from the definition of "certificate=20 extensions".=20 Basically, the text which was specific to "certificate extensions" has=20 been moved into section 4.2.1.=20 Section 4.2 which is called "Certificates Extensions" has been renamed=20 "Extensions".=20 It is specific to extensions which are used by any RFC which wants to use = the syntax and its meaning.=20 All the relationships with "certificate extensions" have been removed in=20 the new section 4.2.=20 [piyush] exisiting 4.2 applies to certificate extension. It does not=20 apply to any other extensions (CRL, Crl Entry or extensions used in 2560,=20 5055 or any other ARFC). Even within 5280 there are separate sections to=20 define what ?Extensions? means in context of CRLs and CRL entries. You will find here after the (1) new proposed text, (2) the current text,=20 and (3) an extract from X.509.=20 NEW PROPOSED TEXT:=20 4.1.2.9. Extensions This field MUST only appear if the version is 3 (Section 4.1.2.1).=20 If present, this field is a SEQUENCE of one or more extensions. =20 The format and content of the extensions field are defined in=20 section 4.2.=20 4.2. Extensions=20 The extensions field allows addition of new fields to a structure=20 without modification to the ASN.1 definition. An extension field=20 consists of an extension identifier, a criticality flag, and an=20 encoding of a data value of an ASN.1 type associated with the=20 identified extension.=20 Each extension includes an OID and an ASN.1 structure. When an=20 extension appears in a structure , the OID appears as the field=20 extnID and the corresponding ASN.1 DER encoded structure is the=20 value of the octet string extnValue. A SEQUENCE MUST NOT include=20 more than one instance of a particular extension.=20 [piyush] There could be scenarios outside 5280 where more than one=20 instance of same extensions in a sequence are useful. For those extensions where ordering of individual extensions within=20 the SEQUENCE is significant, the specification of those individual=20 extensions shall include the rules for the significance of the order=20 therein.=20 An extension includes the boolean critical, with a default value of=20 FALSE. The text for each extension specifies the acceptable values=20 for the critical field for implementations conforming to this=20 profile.=20 A processing system MUST reject the content of the SEQUENCE where=20 the extension appears if it encounters a critical extension it does=20 not recognize or a critical extension that contains information that=20 it cannot process.=20 [piyush] which SEQUENCE ? immediate parent or the top level SEQUENCE? I=20 think it depends on the extension that is being defined.=20 A non-critical extension MUST be processed if it is recognized and=20 MAY be ignored if it is not recognized.=20 [piyush] It is relevant in context of 5280 but other specifications should = be free to define their own processing rules. Note that any extension that is flagged non-critical will cause=20 inconsistent behaviour between processing systems that will process=20 the extension and processing systems that do not recognize the=20 extension and will ignore it.=20 =20 4.2.1. Standard Extensions=20 The following sections present recommended extensions used within=20 Internet certificates and standard locations for information. =20 Communities may elect to use additional extensions; however,=20 caution ought to be exercised in adopting any critical extensions=20 in certificates that might prevent use in a general context.=20 The extensions defined for X.509 v3 certificates provide methods for=20 associating additional attributes with users or public keys and for=20 managing relationships between CAs. The X.509 v3 certificate format=20 also allows communities to define private extensions to carry=20 information unique to those communities. =20 Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and=20 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section=20 4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. If=20 the CA issues certificates with an empty sequence for the subject=20 field, the CA MUST support the subject alternative name extension=20 (Section 4.2.1.6). Support for the remaining extensions is OPTIONAL.=20 Conforming CAs MAY support extensions that are not identified within=20 this specification; certificate issuers are cautioned that marking=20 such extensions as critical may inhibit interoperability.=20 At a minimum, applications conforming to this profile MUST recognize=20 the following extensions: key usage (Section 4.2.1.3), certificate=20 policies (Section 4.2.1.4), subject alternative name (Section=20 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints=20 (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended=20 key usage (Section 4.2.1.12), and inhibit anyPolicy (Section=20 4.2.1.14).=20 In addition, applications conforming to this profile SHOULD recognize=20 the authority and subject key identifier (Sections 4.2.1.1 and=20 4.2.1.2) and policy mappings (Section 4.2.1.5) extensions.=20 This section identifies standard certificate extensions defined in=20 [X.509] for use in the Internet PKI.=20 CURRENT TEXT:=20 4.1.2.9. Extensions=20 This field MUST only appear if the version is 3 (Section 4.1.2.1).=20 If present, this field is a SEQUENCE of one or more certificate=20 extensions. The format and content of certificate extensions in the=20 Internet PKI are defined in Section 4.2.=20 4.2. Certificate Extensions=20 The extensions defined for X.509 v3 certificates provide methods for=20 associating additional attributes with users or public keys and for=20 managing relationships between CAs. The X.509 v3 certificate format=20 also allows communities to define private extensions to carry=20 information unique to those communities. Each extension in a=20 certificate is designated as either critical or non-critical. A=20 certificate-using system MUST reject the certificate if it encounters=20 a critical extension it does not recognize or a critical extension=20 that contains information that it cannot process. A non-critical=20 extension MAY be ignored if it is not recognized, but MUST be=20 processed if it is recognized. The following sections present=20 recommended extensions used within Internet certificates and standard=20 locations for information. Communities may elect to use additional=20 extensions; however, caution ought to be exercised in adopting any=20 critical extensions in certificates that might prevent use in a=20 general context.=20 Each extension includes an OID and an ASN.1 structure. When an=20 extension appears in a certificate, the OID appears as the field=20 extnID and the corresponding ASN.1 DER encoded structure is the value=20 of the octet string extnValue. A certificate MUST NOT include more=20 than one instance of a particular extension. For example, a=20 certificate may contain only one authority key identifier extension=20 (Section 4.2.1.1). An extension includes the boolean critical, with=20 a default value of FALSE. The text for each extension specifies the=20 acceptable values for the critical field for CAs conforming to this=20 profile.=20 Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and=20 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section=20 4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. If=20 the CA issues certificates with an empty sequence for the subject=20 field, the CA MUST support the subject alternative name extension=20 (Section 4.2.1.6). Support for the remaining extensions is OPTIONAL.=20 Conforming CAs MAY support extensions that are not identified within=20 this specification; certificate issuers are cautioned that marking=20 such extensions as critical may inhibit interoperability.=20 At a minimum, applications conforming to this profile MUST recognize=20 the following extensions: key usage (Section 4.2.1.3), certificate=20 policies (Section 4.2.1.4), subject alternative name (Section=20 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints=20 (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended=20 key usage (Section 4.2.1.12), and inhibit anyPolicy (Section=20 4.2.1.14).=20 In addition, applications conforming to this profile SHOULD recognize=20 the authority and subject key identifier (Sections 4.2.1.1 and=20 4.2.1.2) and policy mappings (Section 4.2.1.5) extensions.=20 4.2.1. Standard Extensions=20 This section identifies standard certificate extensions defined in=20 [X.509] for use in the Internet PKI. =20 EXTRACT FROM X.509 page 14:=20 The extensions field allows addition of new fields to the structure=20 without modification to the ASN.1 definition.=20 An extension field consists of an extension identifier, a criticality=20 flag, and an encoding of a data value of=20 an ASN.1 type associated with the identified extension.=20 For those extensions where ordering of individual extensions within the=20 SEQUENCE is significant,=20 the specification of those individual extensions shall include the rules=20 for the significance of the order therein.=20 When an implementation processing a certificate does not recognize an=20 extension, if the criticality flag is FALSE,=20 it may ignore that extension. If the criticality flag is TRUE,=20 unrecognized extensions shall cause the structure=20 to be considered invalid, i.e., in a certificate, an unrecognized critical = extension would cause validation of=20 a signature using that certificate to fail.=20 When a certificate-using implementation recognizes and is able to process=20 an extension, then the=20 certificate-using implementation shall process the extension regardless of = the value of the criticality flag.=20 Note that any extension that is flagged non-critical will cause=20 inconsistent behaviour between certificate-using=20 systems that will process the extension and certificate-using systems that = do not recognize the extension and will ignore it.=20 If unknown elements appear within the extension, and the extension is not=20 marked critical, those unknown elements=20 shall be ignored according to the rules of extensibility documented in=20 12.2.2 in ITU-T Rec. X.519 | ISO/IEC 9594-5.=20 Denis=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From piyush@identicate.com Thu Aug 30 08:39:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C3721F853F for ; Thu, 30 Aug 2012 08:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr-Qe91EeBfr for ; Thu, 30 Aug 2012 08:39:07 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 24BAB21F84D4 for ; Thu, 30 Aug 2012 08:39:06 -0700 (PDT) Received: from mail97-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Thu, 30 Aug 2012 15:39:05 +0000 Received: from mail97-ch1 (localhost [127.0.0.1]) by mail97-ch1-R.bigfish.com (Postfix) with ESMTP id E01D82E00DD; Thu, 30 Aug 2012 15:39:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.229; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0610HT005.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI98dI9371Ic89bh1431J148cIc857hzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail97-ch1: domain of identicate.com designates 157.56.244.229 as permitted sender) client-ip=157.56.244.229; envelope-from=piyush@identicate.com; helo=CH1PRD0610HT005.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail97-ch1 (localhost.localdomain [127.0.0.1]) by mail97-ch1 (MessageSwitch) id 1346341143148047_1086; Thu, 30 Aug 2012 15:39:03 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail97-ch1.bigfish.com (Postfix) with ESMTP id 10CE6460247; Thu, 30 Aug 2012 15:39:03 +0000 (UTC) Received: from CH1PRD0610HT005.namprd06.prod.outlook.com (157.56.244.229) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 30 Aug 2012 15:39:02 +0000 Received: from CH1PRD0610MB393.namprd06.prod.outlook.com ([169.254.11.123]) by CH1PRD0610HT005.namprd06.prod.outlook.com ([10.255.151.40]) with mapi id 14.16.0190.008; Thu, 30 Aug 2012 15:39:01 +0000 From: Piyush Jain To: Santosh Chokhani , "denis.pinkas@bull.net" , Sharon Boeyen Thread-Topic: [pkix] Errata in section 5.3 from RFC 5280 Thread-Index: AQHNgIeJt+ZtG1v2/0SUVkmWWswva5dmTUaAgAFaMgCAACh7gIAAAxkAgAAD5ACABgz4AIAAAOcAgAAHYACAAAMOAIABmXUAgAMAEYA= Date: Thu, 30 Aug 2012 15:39:01 +0000 Message-ID: References: <20120822204613.717341A1A8@ld9781.wdf.sap.corp> <3115DBF8-631C-46A1-827B-E6E93B532A47@vigilsec.com> <65DA4BEA501AFC409DF274CC71ED01A53A551F2B@SOTTEXCH10.corp.ad.entrust.com> <4918BCF9-2556-4E9F-9398-2222E62D7E14@vigilsec.com> <65DA4BEA501AFC409DF274CC71ED01A53A551FA6@SOTTEXCH10.corp.ad.entrust.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.25.128.241] Content-Type: multipart/alternative; boundary="_000_AA6BA445CBFDB84785CC1C45DAAE4C7926354BE3CH1PRD0610MB393_" MIME-Version: 1.0 X-OriginatorOrg: identicate.com Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 15:39:09 -0000 --_000_AA6BA445CBFDB84785CC1C45DAAE4C7926354BE3CH1PRD0610MB393_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KQWRkcmVzc2VzIHRoZSBjYXNlIHdoZXJlIGEgUlAgdW5kZXJzdGFuZHMgSURQIGJ1dCBk b2VzIG5vdCB1bmRlcnN0YW5kIENSTElzc3VlcnMuDQpTYW50b3No4oCZcyBwcm9wb3NhbCBjYWxs cyBpdCBvdXQgZXhwbGljaXRseSBtYWtpbmcgaXQgY2xlYXJlci4NCkZyb206IHBraXgtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNh bnRvc2ggQ2hva2hhbmkNClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyOCwgMjAxMiAxMDo0NSBBTQ0K VG86IGRlbmlzLnBpbmthc0BidWxsLm5ldDsgU2hhcm9uIEJvZXllbg0KQ2M6IElFVEYgUEtJWA0K U3ViamVjdDogUmU6IFtwa2l4XSBFcnJhdGEgaW4gc2VjdGlvbiA1LjMgZnJvbSBSRkMgNTI4MA0K DQpEZW5pcyBhbmQgU2hhcm9uLA0KDQpJIHdvdWxkIHByb3Bvc2UgdGhlIGZvbGxvd2luZzoNCg0K DQphKSAgICAgIEluIHRoZSBwZW51bHRpbWF0ZSBzZW50ZW5jZSBvZiB0aGUgZmlyc3QgcGFyYWdy YXBoIG9mIDUuMyByZXBsYWNlIOKAnHN0YXR1cyBvZiBhbnkgY2VydGlmaWNhdGXigJ0gd2l0aCDi gJxzdGF0dXMgb2YgdGhlIGNlcnRpZmljYXRlIHJlcHJlc2VudGVkIGJ5IHRoZSBDUkwgZW50cnni gJ0uDQoNCg0KYikgICAgICBBIGNyaXRpY2FsIGV4dGVuc2lvbiBpbiB0aGUgY3JsRW50cnlFeHRl bnNpb25zIGZpZWxkIG9mIGFuIGVudHJ5IHNoYWxsIGFmZmVjdCBvbmx5IHRoZSBjZXJ0aWZpY2F0 ZSBzcGVjaWZpZWQgaW4gdGhhdCBlbnRyeSwgdW5sZXNzIHRoZXJlIGlzIGEgcmVsYXRlZCBjcml0 aWNhbCBleHRlbnNpb24gaW4gdGhlIGNybEV4dGVuc2lvbnMgZmllbGQgdGhhdCBhZHZlcnRpc2Vz IGEgc3BlY2lhbCB0cmVhdG1lbnQgZm9yIGl0LuKAnSAgSW4gb3JkZXIgdG8gdXNlIHN1Y2ggQ1JM LCB0aGUgcmVseWluZyBwYXJ0eSBtdXN0IGJlIGFibGUgdG8gcHJvY2VzcyBib3RoIHRoZSBjcmxF bnRyeUV4dGVuc2lvbiBhbmQgdGhlIHJlbGF0ZWQgY3JsRXh0ZW5zaW9uLg0KDQpGcm9tOiBwa2l4 LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpw a2l4LWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9y Z10+IE9uIEJlaGFsZiBPZiBkZW5pcy5waW5rYXNAYnVsbC5uZXQ8bWFpbHRvOmRlbmlzLnBpbmth c0BidWxsLm5ldD4NClNlbnQ6IE1vbmRheSwgQXVndXN0IDI3LCAyMDEyIDE6MjAgUE0NClRvOiBT aGFyb24gQm9leWVuDQpDYzogSUVURiBQS0lYDQpTdWJqZWN0OiBSZTogW3BraXhdIEVycmF0YSBp biBzZWN0aW9uIDUuMyBmcm9tIFJGQyA1MjgwDQoNClNoYXJvbiwNCg0KVGhhbmsgeW91IGZvciB0 aGUgcHJvcG9zYWwuDQoNCkkgYmVsaWV2ZSB0aGF0IGEgc2ltcGxpZmljYXRpb24gd291bGQgYmUg cG9zc2libGUsIHNpbmNlIHdlIGRvIG5vdCBkZXNjcmliZSBhbGwgdGhlIGZlYXR1cmVzIG9mICBY LjUwOSBpbiBSRkMgNTI4MDoNCg0KYSkgICAgICBJbiB0aGUgcGVudWx0aW1hdGUgc2VudGVuY2Ug b2YgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiA1LjMgcmVwbGFjZSDigJxzdGF0dXMgb2YgYW55IGNl cnRpZmljYXRl4oCdIHdpdGgg4oCcc3RhdHVzIG9mIHRoaXMgY2VydGlmaWNhdGXigJ0NCmIpICAg ICAgQWRkIGEgbmV3IHNlY29uZCBwYXJhZ3JhcGggaW4gNS4zIHRoYXQgc3RhdGVzIOKAnFRoZXJl Zm9yZSwgYSBjcml0aWNhbCBleHRlbnNpb24gaW4gdGhlIGNybEVudHJ5RXh0ZW5zaW9ucyBmaWVs ZCBvZiBhbiBlbnRyeQ0Kc2hhbGwgYWZmZWN0IG9ubHkgdGhlIGNlcnRpZmljYXRlIHNwZWNpZmll ZCBpbiB0aGF0IGVudHJ5LCB1bmxlc3MgdGhlcmUgaXMgYSByZWxhdGVkIGNyaXRpY2FsIGV4dGVu c2lvbiBpbiB0aGUgY3JsRXh0ZW5zaW9ucyBmaWVsZA0KdGhhdCBhZHZlcnRpc2VzIGEgc3BlY2lh bCB0cmVhdG1lbnQgZm9yIGl0LuKAnQ0KDQpEZW5pcw0KDQoNCg0KRGUgOiAgICAgICAgU2hhcm9u IEJvZXllbiA8c2hhcm9uLmJvZXllbkBlbnRydXN0LmNvbTxtYWlsdG86c2hhcm9uLmJvZXllbkBl bnRydXN0LmNvbT4+DQpBIDogICAgICAgIFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5j b208bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tPj4NCkNjIDogICAgICAgIElFVEYgUEtJWCA8 cGtpeEBpZXRmLm9yZzxtYWlsdG86cGtpeEBpZXRmLm9yZz4+DQpEYXRlIDogICAgICAgIDI3LzA4 LzIwMTIgMTk6MDkNCk9iamV0IDogICAgICAgIFJlOiBbcGtpeF0gRXJyYXRhIGluIHNlY3Rpb24g NS4zIGZyb20gUkZDIDUyODANCkVudm95w6kgcGFyIDogICAgICAgIHBraXgtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KDQoNCkkgdGhpbmsgdGhlIGVhc2llc3Qgd2F5IHRvIGNsYXJpZnkgaXQg d291bGQgYmU6DQoNCmEpICAgICAgSW4gdGhlIHBlbnVsdGltYXRlIHNlbnRlbmNlIG9mIHRoZSBm aXJzdCBwYXJhZ3JhcGggb2YgNS4zIHJlcGxhY2Ug4oCcc3RhdHVzIG9mIGFueSBjZXJ0aWZpY2F0 ZeKAnSB3aXRoIOKAnHN0YXR1cyBvZiB0aGlzIGNlcnRpZmljYXRl4oCdDQpiKSAgICAgIEFkZCBh IG5ldyBzZWNvbmQgcGFyYWdyYXBoIGluIDUuMyB0aGF0IHN0YXRlcyDigJxJZiBhbiBleHRlbnNp b24gYWZmZWN0cyB0aGUgdHJlYXRtZW50IG9mIHRoZSBsaXN0IChlLmcuLCBtdWx0aXBsZSBDUkxz IG5lZWQgdG8gYmUgc2Nhbm5lZCB0byBleGFtaW5lIHRoZSBlbnRpcmUgbGlzdCBvZiByZXZva2Vk IGNlcnRpZmljYXRlcywgb3IgYW4gZW50cnkgbWF5IHJlcHJlc2VudCBhIHJhbmdlIG9mIGNlcnRp ZmljYXRlcyksIHRoZW4gZWl0aGVyIHRoYXQgZXh0ZW5zaW9uIG9yIGEgcmVsYXRlZCBleHRlbnNp b24gc2hhbGwgYmUgaW5kaWNhdGVkIGFzIGNyaXRpY2FsIGluIHRoZSBjcmxFeHRlbnNpb25zZmll bGQuIFRoZXJlZm9yZSwgYSBjcml0aWNhbCBleHRlbnNpb24gaW4gdGhlIGNybEVudHJ5RXh0ZW5z aW9ucyBmaWVsZCBvZiBhbiBlbnRyeSBzaGFsbCBhZmZlY3Qgb25seSB0aGUgY2VydGlmaWNhdGUg c3BlY2lmaWVkIGluIHRoYXQgZW50cnksIHVubGVzcyB0aGVyZSBpcyBhIHJlbGF0ZWQgY3JpdGlj YWwgZXh0ZW5zaW9uIGluIHRoZSBjcmxFeHRlbnNpb25zIGZpZWxkIHRoYXQgYWR2ZXJ0aXNlcyBh IHNwZWNpYWwgdHJlYXRtZW50IGZvciBpdC7igJ0NCg0KRnJvbTogUnVzcyBIb3VzbGV5IFttYWls dG86aG91c2xleUB2aWdpbHNlYy5jb21dDQpTZW50OiBNb25kYXksIEF1Z3VzdCAyNywgMjAxMiAx Mjo0MiBQTQ0KVG86IFNoYXJvbiBCb2V5ZW4NCkNjOiBJRVRGIFBLSVgNClN1YmplY3Q6IFJlOiBb cGtpeF0gRXJyYXRhIGluIHNlY3Rpb24gNS4zIGZyb20gUkZDIDUyODANCg0KU2hhcm9uOg0KDQpU aGFua3MgZm9yIGRpZ2dpbmcgdXAgdGhvc2Ugd29yZHMuICBUaGV5IHN1cHBvcnQgdGhlIHBvc2l0 aW9uIHRoYXQgSSBoYXZlIHN0YXRlZC4NCg0KSG93IGRvIHlvdSBiZWxpZXZlIHRoZSBjbGFyaWZp Y2F0aW9ucyBkb2N1bWVudCBzaG91bGQgY2hhbmdlIHRvIGV4cHJlc3MgdGhpcyBwb2ludD8NCg0K UnVzcw0KDQoNCk9uIEF1ZyAyNywgMjAxMiwgYXQgMTI6MzkgUE0sIFNoYXJvbiBCb2V5ZW4gd3Jv dGU6DQoNCg0KUnVzcywgSSByZWFsaXplIHRoZSBSRkMgNTI4MCByZWZlcmVuY2VzIHRoZSAyMDA1 IGVkaXRpb24gb2YgWC41MDkuIEhvd2V2ZXIgdGhlIDIwMDkgZWRpdGlvbiAoZnJlZWx5IGF2YWls YWJsZSBhdGh0dHA6Ly93d3cueDUwMHN0YW5kYXJkLmNvbS9pbmRleC5waHA/bj1JZy5MYXRlc3RB dmFpbCApIHJldmlzZXMgdGhpcyB0ZXh0IGFnYWluIHNsaWdodGx5IGFuZCBJIHRoaW5rIG1ha2Vz IHRoZSBpbnRlbnQgZXZlbiBjbGVhcmVyLiBJdCBzdGF0ZXMgKGFzIHBhcnQgb2YgdGhlIG1haW4g dGV4dCBhbmQgbm8gbG9uZ2VyIGEgbm90ZSk6DQoNCklmIGFuIGV4dGVuc2lvbiBhZmZlY3RzIHRo ZSB0cmVhdG1lbnQgb2YgdGhlIGxpc3QgKGUuZy4sIG11bHRpcGxlIENSTHMgbmVlZCB0byBiZSBz Y2FubmVkIHRvIGV4YW1pbmUgdGhlIGVudGlyZSBsaXN0IG9mIHJldm9rZWQgY2VydGlmaWNhdGVz LCBvciBhbiBlbnRyeSBtYXkgcmVwcmVzZW50IGEgcmFuZ2Ugb2YgY2VydGlmaWNhdGVzKSwgdGhl biBlaXRoZXIgdGhhdCBleHRlbnNpb24gb3IgYSByZWxhdGVkIGV4dGVuc2lvbiBzaGFsbCBiZSBp bmRpY2F0ZWQgYXMgY3JpdGljYWwgaW4gdGhlIGNybEV4dGVuc2lvbnNmaWVsZC4gVGhlcmVmb3Jl LCBhIGNyaXRpY2FsIGV4dGVuc2lvbiBpbiB0aGUgY3JsRW50cnlFeHRlbnNpb25zIGZpZWxkIG9m IGFuIGVudHJ5IHNoYWxsIGFmZmVjdCBvbmx5IHRoZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQgaW4g dGhhdCBlbnRyeSwgdW5sZXNzIHRoZXJlIGlzIGEgcmVsYXRlZCBjcml0aWNhbCBleHRlbnNpb24g aW4gdGhlIGNybEV4dGVuc2lvbnMgZmllbGQgdGhhdCBhZHZlcnRpc2VzIGEgc3BlY2lhbCB0cmVh dG1lbnQgZm9yIGl0LiBUaGUgb25seSBleGFtcGxlIG9mIHRoaXMgc2l0dWF0aW9uIGRlZmluZWQg aW4gdGhpcyBTcGVjaWZpY2F0aW9uIGlzIHRoZSBjZXJ0aWZpY2F0ZUlzc3VlciBDUkwgZW50cnkg ZXh0ZW5zaW9uIGFuZCB0aGUgcmVsYXRlZCBpc3N1aW5nRGlzdHJpYnV0aW9uUG9pbnQgQ1JMIGV4 dGVuc2lvbiB3aGVuIHRoZWluZGlyZWN0Q1JMIEJvb2xlYW4gZnJvbSB0aGF0IGV4dGVuc2lvbiBp cyBzZXQgdG8gVFJVRS4NCg0KDQpUaGlzIGlzIGNsZWFybHkgdGhlIGNhc2UgZm9yIGNlcnRpZmlj YXRlSXNzdWVyIGFzIHlvdSBpbmRpY2F0ZSBiZWxvdyBhbmQgYXMgeW91IG5vdGUgYmVsb3cgdGhl IG9ubHkgb3RoZXIgMiBzdGFuZGFyZCBjcmwgZW50cnkgZXh0ZW5zaW9ucyBhcmUgaXJyZWxldmFu dCBhcyB0aGV5IGNhbiBvbmx5IGV2ZXIgYmUgbm9uLWNyaXRpY2FsIGFuZCBhZmZlY3Qgb25seSB0 aGUgc2luZ2xlIGlkZW50aWZpZWQgcmV2b2tlZCBjZXJ0aWZpY2F0ZS4gQW55IHByaXZhdGUgZXh0 ZW5zaW9uIHRoYXQgbWlnaHQgYmUgZGVmaW5lZCBhcyBhIGNybEVudHJ5IGV4dGVuc2lvbiB3b3Vs ZCBhbHNvIGhhdmUgdG8gZm9sbG93IHRoYXQgc2FtZSBydWxlIHRvIGJlIGNvbXBsaWFudCB3aXRo IHRoZSBiYXNlIHN0YW5kYXJkLiBJIGRvIGJlbGlldmUgdGhlIDIwMDUgdGV4dCB3YXMgY2xlYXIg YnV0IG9mZmVyIHRoaXMgMjAwOSBhcyBhZGRpdGlvbmFsIGNvbmZpcm1hdGlvbiBvZiB0aGUgaW50 ZW50IChJIHBlcnNvbmFsbHkgZmluZCB0aGlzIHRleHQgZXZlbiBjbGVhcmVyKS4NCg0KQ2hlZXJz LA0KU2hhcm9uDQoNCg0KRnJvbTogcGtpeC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwa2l4LWJv dW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21h aWx0bzpwa2l4LWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgUnVzcyBIb3VzbGV5DQpT ZW50OiBUaHVyc2RheSwgQXVndXN0IDIzLCAyMDEyIDQ6MTUgUE0NClRvOiBTYW50b3NoIENob2to YW5pDQpDYzogSUVURiBQS0lYDQpTdWJqZWN0OiBSZTogW3BraXhdIEVycmF0YSBpbiBzZWN0aW9u IDUuMyBmcm9tIFJGQyA1MjgwDQoNClNhbnRvc2g6DQoNCg0KUkZDIDUyODAgZGVzY3JpYmVzIHRo cmVlIENSTCBFbnRyeSBFeHRlbnNpb25zLCBhbmQgYWxsIG9mIHRoZW0gY29tZSBmcm9tIFguNTA5 Og0KDQogICAgICAgICAgICA1LjMuMS4gIFJlYXNvbiBDb2RlDQogICAgICAgICAgICA1LjMuMi4g IEludmFsaWRpdHkgRGF0ZQ0KICAgICAgICAgICAgNS4zLjMuICBDZXJ0aWZpY2F0ZSBJc3N1ZXIN Cg0KVGhlIGZpcnN0IHR3byBkbyBub3QgaGF2ZSB0aGUgY29uY2VybiB0aGF0IHlvdSBkZXNjcmli ZSwgYW5kIHRoZSB0aGlyZCBvbmUgc2hvdWxkIG9ubHkgYmUgcHJlc2VudCBpZiB0aGUgQ1JMIGlu Y2x1ZGVzIHRoZSBJc3N1aW5nRGlzdHJpYnV0aW9uUG9pbnQgQ1JMIGV4dGVuc2lvbiwgYW5kIHRo YXQgZXh0ZW5zaW9uIGluY2x1ZGVzIHRoZSBpbmRpcmVjdENSTCBzZXQgdG8gVFJVRS4gIFRoZSBJ c3N1aW5nRGlzdHJpYnV0aW9uUG9pbnQgQ1JMIGV4dGVuc2lvbiBtdXN0IGJlIGNyaXRpY2FsLiAg UkZDIDUyODAgc2F5czoNCg0KICAgVGhlIGlzc3VpbmcgZGlzdHJpYnV0aW9uIHBvaW50IGlzIGEg Y3JpdGljYWwgQ1JMIGV4dGVuc2lvbiB0aGF0DQogICBpZGVudGlmaWVzIHRoZSBDUkwgZGlzdHJp YnV0aW9uIHBvaW50IGFuZCBzY29wZSBmb3IgYSBwYXJ0aWN1bGFyIENSTCwNCiAgIGFuZCBpdCBp bmRpY2F0ZXMgd2hldGhlciB0aGUgQ1JMIGNvdmVycyByZXZvY2F0aW9uIGZvciBlbmQgZW50aXR5 DQogICBjZXJ0aWZpY2F0ZXMgb25seSwgQ0EgY2VydGlmaWNhdGVzIG9ubHksIGF0dHJpYnV0ZSBj ZXJ0aWZpY2F0ZXMgb25seSwNCiAgIG9yIGEgbGltaXRlZCBzZXQgb2YgcmVhc29uIGNvZGVzLiAg QWx0aG91Z2ggdGhlIGV4dGVuc2lvbiBpcw0KICAgY3JpdGljYWwsIGNvbmZvcm1pbmcgaW1wbGVt ZW50YXRpb25zIGFyZSBub3QgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGlzDQogICBleHRlbnNpb24u ICBIb3dldmVyLCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3Qgc3VwcG9ydCB0aGlzDQogICBl eHRlbnNpb24gTVVTVCBlaXRoZXIgdHJlYXQgdGhlIHN0YXR1cyBvZiBhbnkgY2VydGlmaWNhdGUg bm90IGxpc3RlZA0KICAgb24gdGhpcyBDUkwgYXMgdW5rbm93biBvciBsb2NhdGUgYW5vdGhlciBD UkwgdGhhdCBkb2VzIG5vdCBjb250YWluDQogICBhbnkgdW5yZWNvZ25pemVkIGNyaXRpY2FsIGV4 dGVuc2lvbnMuDQoNClRvIG15IG1pbmQsIHRoZSBzdXBwb3J0IGZvciB0aGUgY3JpdGljYWwgSXNz dWluZ0Rpc3RyaWJ1dGlvblBvaW50IENSTCBleHRlbnNpb24gaW5jbHVkZXMgdGhlIHByb3BlciBz dXBwb3J0IGZvciB0aGUgQ2VydGlmaWNhdGUgSXNzdWVyIENSTCBlbnRyeSBleHRlbnNpb24uDQoN ClJ1c3MNCg0KDQpPbiBBdWcgMjMsIDIwMTIsIGF0IDQ6MDEgUE0sIFNhbnRvc2ggQ2hva2hhbmkg d3JvdGU6DQoNCg0KDQpSdXNzLA0KDQpUaGUgcHJvYmxlbSB3aXRoIERlbmlz4oCZcyBwcm9wb3Nh bCBpcyB0aGF0IGhlIHdhbnRzIHRvIHJlcGxhY2UgdGhlIHRleHQgb2Ygbm90IHVzaW5nIHRoZSBD UkwuDQoNCkkgaGF2ZSBjaXRlZCBhIHNwZWNpZmljIGV4YW1wbGUgaW4gNTI4MCBpdHNlbGYgd2hl cmUgYW4gZW50cnkgZXh0ZW5zaW9uIHNjb3BlIGdvZXMgYmV5b25kIHRoYXQgb2YgdGhlIGVudHJ5 LiAgSXQgcG90ZW50aWFsbHkgaW1wYWN0cyBzdWJzZXF1ZW50IGVudHJpZXMuDQoNClRodXMsIERl bmlz4oCZcyBwcm9wb3NhbCBpcyB1bmFjY2VwdGFibGUuICBJZiBoZSBqdXN0IHdhbnRlZCB0byBh ZGQgdGhlIHNlbnRlbmNlIGFzIG9wcG9zZWQgdG8gcmVwbGFjZSwgaXQgd291bGQgYmUgZmluZS4N Cg0KSW4gZ2VuZXJhbCwgdW5sZXNzIDUyODAgYW5kIFguNTA5IHN0YXRlZCB0aGF0IGFuIGVudHJ5 IGV4dGVuc2lvbiBjYW5ub3QgaW1wYWN0IHNlbWFudGljcyBvZiBhbnl0aGluZyBpbiB0aGUgQ1JM IG90aGVyIHRoYW4gdGhlIGVudHJ5IGl0c2VsZiwgd2hhdCB5b3Ugc2F5IGlzIHVuYWNjZXB0YWJs ZSBhbmQgcG90ZW50aWFsbHkgaW5zZWN1cmUuDQoNCkZyb206IHBraXgtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnBraXgtYm91bmNlc0BpZXRm Lm9yZ108bWFpbHRvOlttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVoYWxmIE9m IFJ1c3MgSG91c2xleQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyMywgMjAxMiAzOjUwIFBNDQpU bzogZGVuaXMucGlua2FzQGJ1bGwubmV0PG1haWx0bzpkZW5pcy5waW5rYXNAYnVsbC5uZXQ+DQpD YzogSUVURiBQS0lYDQpTdWJqZWN0OiBSZTogW3BraXhdIEVycmF0YSBpbiBzZWN0aW9uIDUuMyBm cm9tIFJGQyA1MjgwDQoNCg0KSSBhZ3JlZSB3aXRoIHRoZSBwcm9wb3NhbCB0aGF0IERlbmlzIG1h a2VzLiAgSSBzdXBwb3J0IGhpcyBwcm9wb3NlZCB0ZXh0Lg0KDQpUaGlzIHZhbGlkYXRlcyBteSB0 ZXh0IHByb3Bvc2FsIHdoaWNoIHN0aWxsIGlzOg0KDQogIElmIGEgQ1JMIGNvbnRhaW5zIGEgY3Jp dGljYWwgQ1JMIGVudHJ5IGV4dGVuc2lvbiB0aGF0IHRoZSBhcHBsaWNhdGlvbg0KIGNhbm5vdCBw cm9jZXNzLCB0aGVuIHRoZSBhcHBsaWNhdGlvbiBNVVNUIE5PVCB1c2UgdGhhdCBDUkwgZW50cnkg dG8NCiBkZXRlcm1pbmUgdGhlIHN0YXR1cyBvZiB0aGlzIGNlcnRpZmljYXRlIi4gOg0KDQpSdXNz DQoNCiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGtp eCBtYWlsaW5nIGxpc3QNCnBraXhAaWV0Zi5vcmc8bWFpbHRvOnBraXhAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXgNCg== --_000_AA6BA445CBFDB84785CC1C45DAAE4C7926354BE3CH1PRD0610MB393_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnR0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206 MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEOw0KCWZvbnQtd2VpZ2h0Om5v cm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTAzMzU3NDgzNzsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTc2NDYxMTcz MCAxNDIzMDc0MjMwIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjM5LjBwdDsNCgl0ZXh0LWluZGVudDotMjEuMHB0O30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0 MzsxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5BZGRyZXNzZXMgdGhlIGNhc2Ugd2hlcmUgYSBSUCB1bmRlcnN0YW5kcyBJ RFAgYnV0IGRvZXMgbm90IHVuZGVyc3RhbmQgQ1JMSXNzdWVycy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+U2FudG9zaOKAmXMgcHJvcG9zYWwgY2FsbHMgaXQgb3V0IGV4cGxpY2l0bHkg bWFraW5nIGl0IGNsZWFyZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcGtpeC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 cGtpeC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TYW50b3NoIENob2to YW5pPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAyOCwgMjAxMiAxMDo0NSBBTTxi cj4NCjxiPlRvOjwvYj4gZGVuaXMucGlua2FzQGJ1bGwubmV0OyBTaGFyb24gQm9leWVuPGJyPg0K PGI+Q2M6PC9iPiBJRVRGIFBLSVg8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtwa2l4XSBFcnJh dGEgaW4gc2VjdGlvbiA1LjMgZnJvbSBSRkMgNTI4MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5EZW5pcyBhbmQgU2hhcm9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCBwcm9wb3NlIHRoZSBmb2xsb3dpbmc6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzkuMHB0O3Rl eHQtaW5kZW50Oi0yMS4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzAwNDA4MCI+SW4gdGhlIHBlbnVsdGltYXRlIHNlbnRlbmNlIG9mIHRoZSBmaXJzdCBwYXJhZ3Jh cGggb2YgNS4zIHJlcGxhY2Ug4oCcc3RhdHVzIG9mIGFueSBjZXJ0aWZpY2F0ZeKAnSB3aXRoIOKA nHN0YXR1cyBvZiB0aGUgY2VydGlmaWNhdGUgcmVwcmVzZW50ZWQgYnkgdGhlIENSTA0KIGVudHJ5 4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM5LjBw dDt0ZXh0LWluZGVudDotMjEuMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5iKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxMDQxNjAiPkEgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZQ0KPGI+Y3JsRW50cnlFeHRl bnNpb25zPC9iPiBmaWVsZCBvZiBhbiBlbnRyeSBzaGFsbCBhZmZlY3Qgb25seSB0aGUgY2VydGlm aWNhdGUgc3BlY2lmaWVkIGluIHRoYXQgZW50cnksIHVubGVzcyB0aGVyZSBpcyBhIHJlbGF0ZWQg Y3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZQ0KPGI+Y3JsRXh0ZW5zaW9uczwvYj4gZmllbGQgdGhh dCBhZHZlcnRpc2VzIGEgc3BlY2lhbCB0cmVhdG1lbnQgZm9yIGl0LuKAnSZuYnNwOyBJbiBvcmRl ciB0byB1c2Ugc3VjaCBDUkwsIHRoZSByZWx5aW5nIHBhcnR5IG11c3QgYmUgYWJsZSB0byBwcm9j ZXNzIGJvdGggdGhlDQo8Yj5jcmxFbnRyeUV4dGVuc2lvbiA8L2I+YW5kIHRoZSByZWxhdGVkIDxi PmNybEV4dGVuc2lvbi48L2I+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJl Zj0ibWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZyI+cGtpeC1ib3VuY2VzQGlldGYub3JnPC9h PiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpwa2l4LWJvdW5jZXNAaWV0Zi5vcmddIj4NClttYWls dG86cGtpeC1ib3VuY2VzQGlldGYub3JnXTwvYT4gPGI+T24gQmVoYWxmIE9mIDwvYj48YSBocmVm PSJtYWlsdG86ZGVuaXMucGlua2FzQGJ1bGwubmV0Ij5kZW5pcy5waW5rYXNAYnVsbC5uZXQ8L2E+ PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDI3LCAyMDEyIDE6MjAgUE08YnI+DQo8 Yj5Ubzo8L2I+IFNoYXJvbiBCb2V5ZW48YnI+DQo8Yj5DYzo8L2I+IElFVEYgUEtJWDxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3BraXhdIEVycmF0YSBpbiBzZWN0aW9uIDUuMyBmcm9tIFJGQyA1 MjgwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5TaGFyb24sPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+VGhhbmsgeW91IGZvciB0aGUgcHJvcG9zYWwuPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBiZWxpZXZlIHRoYXQgYSBzaW1wbGlmaWNhdGlvbiB3b3Vs ZCBiZSBwb3NzaWJsZSwgc2luY2Ugd2UgZG8gbm90IGRlc2NyaWJlIGFsbCB0aGUgZmVhdHVyZXMg b2YgJm5ic3A7WC41MDkgaW4gUkZDIDUyODA6PC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPmEpICZuYnNwOyAmbmJzcDsgJm5ic3A7 SW4gdGhlIHBlbnVsdGltYXRlIHNlbnRlbmNlIG9mIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgNS4z IHJlcGxhY2Ug4oCcc3RhdHVzIG9mIGFueSBjZXJ0aWZpY2F0ZeKAnSB3aXRoIOKAnHN0YXR1cyBv ZiB0aGlzIGNlcnRpZmljYXRl4oCdDQo8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDQwODAiPmIpICZuYnNwOyAmbmJzcDsgJm5ic3A7QWRkIGEgbmV3IHNl Y29uZCBwYXJhZ3JhcGggaW4gNS4zIHRoYXQgc3RhdGVzIOKAnDwvc3Bhbj48aT48c3BhbiBzdHls ZT0iY29sb3I6IzEwNDE2MCI+VGhlcmVmb3JlLCBhIGNyaXRpY2FsIGV4dGVuc2lvbiBpbiB0aGUN Cjwvc3Bhbj48L2k+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxMDQxNjAi PmNybEVudHJ5RXh0ZW5zaW9uczwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzEwNDE2MCI+DQo8 L3NwYW4+PC9pPjwvYj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzEwNDE2MCI+ZmllbGQgb2YgYW4g ZW50cnk8YnI+DQpzaGFsbCBhZmZlY3Qgb25seSB0aGUgY2VydGlmaWNhdGUgc3BlY2lmaWVkIGlu IHRoYXQgZW50cnksIHVubGVzcyB0aGVyZSBpcyBhIHJlbGF0ZWQgY3JpdGljYWwgZXh0ZW5zaW9u IGluIHRoZQ0KPGI+Y3JsRXh0ZW5zaW9uczwvYj4gZmllbGQgPGJyPg0KdGhhdCBhZHZlcnRpc2Vz IGEgc3BlY2lhbCB0cmVhdG1lbnQgZm9yIGl0LuKAnTwvc3Bhbj48L2k+IDxicj4NCjxicj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlbmlzPC9zcGFuPiA8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+RGUgOiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TaGFy b24gQm9leWVuICZsdDs8YSBocmVmPSJtYWlsdG86c2hhcm9uLmJvZXllbkBlbnRydXN0LmNvbSI+ c2hhcm9uLmJvZXllbkBlbnRydXN0LmNvbTwvYT4mZ3Q7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPkEgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SdXNzIEhvdXNsZXkgJmx0Ozxh IGhyZWY9Im1haWx0bzpob3VzbGV5QHZpZ2lsc2VjLmNvbSI+aG91c2xleUB2aWdpbHNlYy5jb208 L2E+Jmd0Ozwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1 RjVGIj5DYyZuYnNwOzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SUVURiBQS0lYICZsdDs8YSBocmVmPSJtYWlsdG86cGtpeEBpZXRm Lm9yZyI+cGtpeEBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPkRhdGUgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yNy8wOC8yMDEyIDE5OjA5PC9zcGFu Pg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPk9iamV0IDog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+UmU6IFtwa2l4XSBFcnJhdGEgaW4gc2VjdGlvbiA1LjMgZnJvbSBSRkMgNTI4MDwvc3Bhbj4N Cjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5FbnZvecOpIHBh ciA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxhIGhyZWY9Im1haWx0bzpwa2l4LWJvdW5jZXNAaWV0Zi5vcmciPnBraXgtYm91bmNl c0BpZXRmLm9yZzwvYT48L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXpl PSIyIiB3aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0FDQTg5OSIgYWxpZ249 ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMwMDQwODAiPkkgdGhpbmsgdGhlIGVhc2llc3Qgd2F5IHRvIGNsYXJpZnkgaXQgd291 bGQgYmU6PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw MDQwODAiPiZuYnNwOzwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMDA0MDgwIj5hKSAmbmJzcDsgJm5ic3A7ICZuYnNwO0luIHRoZSBwZW51bHRpbWF0ZSBz ZW50ZW5jZSBvZiB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIDUuMyByZXBsYWNlIOKAnHN0YXR1cyBv ZiBhbnkgY2VydGlmaWNhdGXigJ0gd2l0aCDigJxzdGF0dXMgb2YgdGhpcyBjZXJ0aWZpY2F0ZeKA nQ0KPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA0MDgw Ij5iKSAmbmJzcDsgJm5ic3A7ICZuYnNwO0FkZCBhIG5ldyBzZWNvbmQgcGFyYWdyYXBoIGluIDUu MyB0aGF0IHN0YXRlcyDigJw8L3NwYW4+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMDQxNjAiPklm IGFuIGV4dGVuc2lvbiBhZmZlY3RzIHRoZSB0cmVhdG1lbnQgb2YgdGhlIGxpc3QgKGUuZy4sIG11 bHRpcGxlIENSTHMgbmVlZCB0byBiZSBzY2FubmVkDQogdG8gZXhhbWluZSB0aGUgZW50aXJlIGxp c3Qgb2YgcmV2b2tlZCBjZXJ0aWZpY2F0ZXMsIG9yIGFuIGVudHJ5IG1heSByZXByZXNlbnQgYSBy YW5nZSBvZiBjZXJ0aWZpY2F0ZXMpLCB0aGVuIGVpdGhlciB0aGF0IGV4dGVuc2lvbiBvciBhIHJl bGF0ZWQgZXh0ZW5zaW9uIHNoYWxsIGJlIGluZGljYXRlZCBhcyBjcml0aWNhbCBpbiB0aGUNCjwv c3Bhbj48L2k+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxMDQxNjAiPmNy bEV4dGVuc2lvbnM8L3NwYW4+PC9pPjwvYj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzEwNDE2MCI+ ZmllbGQuIFRoZXJlZm9yZSwgYSBjcml0aWNhbCBleHRlbnNpb24gaW4gdGhlDQo8L3NwYW4+PC9p PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMTA0MTYwIj5jcmxFbnRyeUV4 dGVuc2lvbnM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMDQxNjAiPg0KPC9zcGFuPjwvaT48 L2I+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMDQxNjAiPmZpZWxkIG9mIGFuIGVudHJ5IHNoYWxs IGFmZmVjdCBvbmx5IHRoZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQgaW4gdGhhdCBlbnRyeSwgdW5s ZXNzIHRoZXJlIGlzIGEgcmVsYXRlZCBjcml0aWNhbCBleHRlbnNpb24gaW4gdGhlDQo8Yj5jcmxF eHRlbnNpb25zPC9iPiBmaWVsZCB0aGF0IGFkdmVydGlzZXMgYSBzcGVjaWFsIHRyZWF0bWVudCBm b3IgaXQu4oCdPC9zcGFuPjwvaT4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMDA0MDgwIj4mbmJzcDs8L3NwYW4+DQo8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUnVz cyBIb3VzbGV5IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGI+PGJyPg0KU2VudDo8L2I+ IE1vbmRheSwgQXVndXN0IDI3LCAyMDEyIDEyOjQyIFBNPGI+PGJyPg0KVG86PC9iPiBTaGFyb24g Qm9leWVuPGI+PGJyPg0KQ2M6PC9iPiBJRVRGIFBLSVg8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6 IFtwa2l4XSBFcnJhdGEgaW4gc2VjdGlvbiA1LjMgZnJvbSBSRkMgNTI4MDwvc3Bhbj4gPGJyPg0K Jm5ic3A7IDxicj4NClNoYXJvbjogPGJyPg0KJm5ic3A7IDxicj4NClRoYW5rcyBmb3IgZGlnZ2lu ZyB1cCB0aG9zZSB3b3Jkcy4gJm5ic3A7VGhleSBzdXBwb3J0IHRoZSBwb3NpdGlvbiB0aGF0IEkg aGF2ZSBzdGF0ZWQuDQo8YnI+DQombmJzcDsgPGJyPg0KSG93IGRvIHlvdSBiZWxpZXZlIHRoZSBj bGFyaWZpY2F0aW9ucyBkb2N1bWVudCBzaG91bGQgY2hhbmdlIHRvIGV4cHJlc3MgdGhpcyBwb2lu dD8NCjxicj4NCiZuYnNwOyA8YnI+DQpSdXNzIDxicj4NCiZuYnNwOyA8YnI+DQombmJzcDsgPGJy Pg0KT24gQXVnIDI3LCAyMDEyLCBhdCAxMjozOSBQTSwgU2hhcm9uIEJvZXllbiB3cm90ZTogPGJy Pg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAi PlJ1c3MsIEkgcmVhbGl6ZSB0aGUgUkZDIDUyODAgcmVmZXJlbmNlcyB0aGUgMjAwNSBlZGl0aW9u IG9mIFguNTA5LiBIb3dldmVyIHRoZSAyMDA5IGVkaXRpb24gKGZyZWVseSBhdmFpbGFibGUgYXQ8 L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy54NTAwc3RhbmRhcmQuY29tL2luZGV4LnBocD9uPUln LkxhdGVzdEF2YWlsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHA6Ly93d3cueDUw MHN0YW5kYXJkLmNvbS9pbmRleC5waHA/bj1JZy5MYXRlc3RBdmFpbDwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPg0KICkgcmV2aXNlcyB0aGlzIHRl eHQgYWdhaW4gc2xpZ2h0bHkgYW5kIEkgdGhpbmsgbWFrZXMgdGhlIGludGVudCBldmVuIGNsZWFy ZXIuIEl0IHN0YXRlcyAoYXMgcGFydCBvZiB0aGUgbWFpbiB0ZXh0IGFuZCBubyBsb25nZXIgYSBu b3RlKTo8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAw NDA4MCI+Jm5ic3A7PC9zcGFuPg0KPGJyPg0KPGk+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+SWYg YW4gZXh0ZW5zaW9uIGFmZmVjdHMgdGhlIHRyZWF0bWVudCBvZiB0aGUgbGlzdCAoZS5nLiwgbXVs dGlwbGUgQ1JMcyBuZWVkIHRvIGJlIHNjYW5uZWQgdG8gZXhhbWluZSB0aGUgZW50aXJlIGxpc3Qg b2YgcmV2b2tlZCBjZXJ0aWZpY2F0ZXMsIG9yIGFuIGVudHJ5IG1heSByZXByZXNlbnQgYSByYW5n ZSBvZiBjZXJ0aWZpY2F0ZXMpLCB0aGVuIGVpdGhlciB0aGF0IGV4dGVuc2lvbiBvciBhIHJlbGF0 ZWQNCiBleHRlbnNpb24gc2hhbGwgYmUgaW5kaWNhdGVkIGFzIGNyaXRpY2FsIGluIHRoZSA8L3Nw YW4+PC9pPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPmNybEV4dGVu c2lvbnM8L3NwYW4+PC9pPjwvYj48aT48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5maWVsZC4gVGhl cmVmb3JlLCBhIGNyaXRpY2FsIGV4dGVuc2lvbiBpbiB0aGUNCjwvc3Bhbj48L2k+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+Y3JsRW50cnlFeHRlbnNpb25zPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPg0KPC9zcGFuPjwvaT48L2I+PGk+PHNwYW4gc3R5bGU9 ImNvbG9yOnJlZCI+ZmllbGQgb2YgYW4gZW50cnkgc2hhbGwgYWZmZWN0IG9ubHkgdGhlIGNlcnRp ZmljYXRlIHNwZWNpZmllZCBpbiB0aGF0IGVudHJ5LCB1bmxlc3MgdGhlcmUgaXMgYSByZWxhdGVk IGNyaXRpY2FsIGV4dGVuc2lvbiBpbiB0aGUNCjxiPmNybEV4dGVuc2lvbnM8L2I+IGZpZWxkIHRo YXQgYWR2ZXJ0aXNlcyBhIHNwZWNpYWwgdHJlYXRtZW50IGZvciBpdC4gVGhlIG9ubHkgZXhhbXBs ZSBvZiB0aGlzIHNpdHVhdGlvbiBkZWZpbmVkIGluIHRoaXMgU3BlY2lmaWNhdGlvbiBpcyB0aGUN Cjwvc3Bhbj48L2k+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+Y2Vy dGlmaWNhdGVJc3N1ZXI8L3NwYW4+PC9pPjwvYj48aT48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4g Q1JMIGVudHJ5IGV4dGVuc2lvbiBhbmQgdGhlIHJlbGF0ZWQNCjwvc3Bhbj48L2k+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+aXNzdWluZ0Rpc3RyaWJ1dGlvblBvaW50 PC9zcGFuPjwvaT48L2I+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+IENSTCBleHRlbnNpb24g d2hlbiB0aGU8Yj5pbmRpcmVjdENSTA0KPC9iPkJvb2xlYW4gZnJvbSB0aGF0IGV4dGVuc2lvbiBp cyBzZXQgdG8gPC9zcGFuPjwvaT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 cmVkIj5UUlVFPC9zcGFuPjwvaT48L2I+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Ljwvc3Bh bj48L2k+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNDA4MCI+ Jm5ic3A7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw MDQwODAiPiZuYnNwOzwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMDA0MDgwIj5UaGlzIGlzIGNsZWFybHkgdGhlIGNhc2UgZm9yIGNlcnRpZmljYXRlSXNz dWVyIGFzIHlvdSBpbmRpY2F0ZSBiZWxvdyBhbmQgYXMgeW91IG5vdGUgYmVsb3cgdGhlIG9ubHkg b3RoZXIgMiBzdGFuZGFyZCBjcmwgZW50cnkgZXh0ZW5zaW9ucyBhcmUgaXJyZWxldmFudCBhcyB0 aGV5IGNhbiBvbmx5IGV2ZXIgYmUNCiBub24tY3JpdGljYWwgYW5kIGFmZmVjdCBvbmx5IHRoZSBz aW5nbGUgaWRlbnRpZmllZCByZXZva2VkIGNlcnRpZmljYXRlLiBBbnkgcHJpdmF0ZSBleHRlbnNp b24gdGhhdCBtaWdodCBiZSBkZWZpbmVkIGFzIGEgY3JsRW50cnkgZXh0ZW5zaW9uIHdvdWxkIGFs c28gaGF2ZSB0byBmb2xsb3cgdGhhdCBzYW1lIHJ1bGUgdG8gYmUgY29tcGxpYW50IHdpdGggdGhl IGJhc2Ugc3RhbmRhcmQuIEkgZG8gYmVsaWV2ZSB0aGUgMjAwNSB0ZXh0IHdhcyBjbGVhcg0KIGJ1 dCBvZmZlciB0aGlzIDIwMDkgYXMgYWRkaXRpb25hbCBjb25maXJtYXRpb24gb2YgdGhlIGludGVu dCAoSSBwZXJzb25hbGx5IGZpbmQgdGhpcyB0ZXh0IGV2ZW4gY2xlYXJlcikuPC9zcGFuPg0KPGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPiZuYnNwOzwvc3Bh bj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA0MDgwIj5DaGVl cnMsPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQw ODAiPlNoYXJvbjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDA0MDgwIj4mbmJzcDs8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzAwNDA4MCI+Jm5ic3A7PC9zcGFuPg0KPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPnBraXgtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOnBr aXgtYm91bmNlc0BpZXRmLm9yZ10iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5bbWFpbHRv OnBraXgtYm91bmNlc0BpZXRmLm9yZ108L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UnVzcyBIb3VzbGV5PGI+PGJyPg0KU2VudDo8L2I+ IFRodXJzZGF5LCBBdWd1c3QgMjMsIDIwMTIgNDoxNSBQTTxiPjxicj4NClRvOjwvYj4gU2FudG9z aCBDaG9raGFuaTxiPjxicj4NCkNjOjwvYj4gSUVURiBQS0lYPGI+PGJyPg0KU3ViamVjdDo8L2I+ IFJlOiBbcGtpeF0gRXJyYXRhIGluIHNlY3Rpb24gNS4zIGZyb20gUkZDIDUyODA8L3NwYW4+IDxi cj4NCiZuYnNwOyA8YnI+DQpTYW50b3NoOiA8YnI+DQombmJzcDsgPGJyPg0KJm5ic3A7IDxicj4N ClJGQyA1MjgwIGRlc2NyaWJlcyB0aHJlZSBDUkwgRW50cnkgRXh0ZW5zaW9ucywgYW5kIGFsbCBv ZiB0aGVtIGNvbWUgZnJvbSBYLjUwOTogPGJyPg0KJm5ic3A7IDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDUuMy4xLiAmbmJzcDtSZWFzb24gQ29kZSA8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA1LjMuMi4gJm5ic3A7 SW52YWxpZGl0eSBEYXRlIDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDUuMy4zLiAmbmJzcDtDZXJ0aWZpY2F0ZSBJc3N1ZXIgPGJyPg0KJm5ic3A7IDxicj4N ClRoZSBmaXJzdCB0d28gZG8gbm90IGhhdmUgdGhlIGNvbmNlcm4gdGhhdCB5b3UgZGVzY3JpYmUs IGFuZCB0aGUgdGhpcmQgb25lIHNob3VsZCBvbmx5IGJlIHByZXNlbnQgaWYgdGhlIENSTCBpbmNs dWRlcyB0aGUgSXNzdWluZ0Rpc3RyaWJ1dGlvblBvaW50IENSTCBleHRlbnNpb24sIGFuZCB0aGF0 IGV4dGVuc2lvbiBpbmNsdWRlcyB0aGUgaW5kaXJlY3RDUkwgc2V0IHRvIFRSVUUuICZuYnNwO1Ro ZSBJc3N1aW5nRGlzdHJpYnV0aW9uUG9pbnQgQ1JMIGV4dGVuc2lvbg0KIG11c3QgYmUgY3JpdGlj YWwuICZuYnNwO1JGQyA1MjgwIHNheXM6IDxicj4NCiZuYnNwOyA8YnI+DQombmJzcDsgJm5ic3A7 VGhlIGlzc3VpbmcgZGlzdHJpYnV0aW9uIHBvaW50IGlzIGEgY3JpdGljYWwgQ1JMIGV4dGVuc2lv biB0aGF0IDxicj4NCiZuYnNwOyAmbmJzcDtpZGVudGlmaWVzIHRoZSBDUkwgZGlzdHJpYnV0aW9u IHBvaW50IGFuZCBzY29wZSBmb3IgYSBwYXJ0aWN1bGFyIENSTCwgPGJyPg0KJm5ic3A7ICZuYnNw O2FuZCBpdCBpbmRpY2F0ZXMgd2hldGhlciB0aGUgQ1JMIGNvdmVycyByZXZvY2F0aW9uIGZvciBl bmQgZW50aXR5IDxicj4NCiZuYnNwOyAmbmJzcDtjZXJ0aWZpY2F0ZXMgb25seSwgQ0EgY2VydGlm aWNhdGVzIG9ubHksIGF0dHJpYnV0ZSBjZXJ0aWZpY2F0ZXMgb25seSwgPGJyPg0KJm5ic3A7ICZu YnNwO29yIGEgbGltaXRlZCBzZXQgb2YgcmVhc29uIGNvZGVzLiAmbmJzcDtBbHRob3VnaCB0aGUg ZXh0ZW5zaW9uIGlzIDxicj4NCiZuYnNwOyAmbmJzcDtjcml0aWNhbCwgY29uZm9ybWluZyBpbXBs ZW1lbnRhdGlvbnMgYXJlIG5vdCByZXF1aXJlZCB0byBzdXBwb3J0IHRoaXMgPGJyPg0KJm5ic3A7 ICZuYnNwO2V4dGVuc2lvbi4gJm5ic3A7SG93ZXZlciwgaW1wbGVtZW50YXRpb25zIHRoYXQgZG8g bm90IHN1cHBvcnQgdGhpcyA8YnI+DQombmJzcDsgJm5ic3A7ZXh0ZW5zaW9uIE1VU1QgZWl0aGVy IHRyZWF0IHRoZSBzdGF0dXMgb2YgYW55IGNlcnRpZmljYXRlIG5vdCBsaXN0ZWQgPGJyPg0KJm5i c3A7ICZuYnNwO29uIHRoaXMgQ1JMIGFzIHVua25vd24gb3IgbG9jYXRlIGFub3RoZXIgQ1JMIHRo YXQgZG9lcyBub3QgY29udGFpbiA8YnI+DQombmJzcDsgJm5ic3A7YW55IHVucmVjb2duaXplZCBj cml0aWNhbCBleHRlbnNpb25zLiA8YnI+DQombmJzcDsgPGJyPg0KVG8gbXkgbWluZCwgdGhlIHN1 cHBvcnQgZm9yIHRoZSBjcml0aWNhbCBJc3N1aW5nRGlzdHJpYnV0aW9uUG9pbnQgQ1JMIGV4dGVu c2lvbiBpbmNsdWRlcyB0aGUgcHJvcGVyIHN1cHBvcnQgZm9yIHRoZSBDZXJ0aWZpY2F0ZSBJc3N1 ZXIgQ1JMIGVudHJ5IGV4dGVuc2lvbi4NCjxicj4NCiZuYnNwOyA8YnI+DQpSdXNzIDxicj4NCiZu YnNwOyA8YnI+DQombmJzcDsgPGJyPg0KT24gQXVnIDIzLCAyMDEyLCBhdCA0OjAxIFBNLCBTYW50 b3NoIENob2toYW5pIHdyb3RlOiA8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwNDA4MCI+UnVzcyw8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNDA4MCI+Jm5ic3A7PC9zcGFuPg0KPGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPlRoZSBwcm9ibGVtIHdpdGggRGVuaXPi gJlzIHByb3Bvc2FsIGlzIHRoYXQgaGUgd2FudHMgdG8gcmVwbGFjZSB0aGUgdGV4dCBvZiBub3Qg dXNpbmcgdGhlIENSTC48L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwNDA4MCI+Jm5ic3A7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMwMDQwODAiPkkgaGF2ZSBjaXRlZCBhIHNwZWNpZmljIGV4YW1wbGUgaW4gNTI4MCBp dHNlbGYgd2hlcmUgYW4gZW50cnkgZXh0ZW5zaW9uIHNjb3BlIGdvZXMgYmV5b25kIHRoYXQgb2Yg dGhlIGVudHJ5LiAmbmJzcDtJdCBwb3RlbnRpYWxseSBpbXBhY3RzIHN1YnNlcXVlbnQgZW50cmll cy48L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNDA4MCI+ Jm5ic3A7PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQw ODAiPlRodXMsIERlbmlz4oCZcyBwcm9wb3NhbCBpcyB1bmFjY2VwdGFibGUuICZuYnNwO0lmIGhl IGp1c3Qgd2FudGVkIHRvIGFkZCB0aGUgc2VudGVuY2UgYXMgb3Bwb3NlZCB0byByZXBsYWNlLCBp dCB3b3VsZCBiZSBmaW5lLjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMDA0MDgwIj4mbmJzcDs8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzAwNDA4MCI+SW4gZ2VuZXJhbCwgdW5sZXNzIDUyODAgYW5kIFguNTA5IHN0YXRl ZCB0aGF0IGFuIGVudHJ5IGV4dGVuc2lvbiBjYW5ub3QgaW1wYWN0IHNlbWFudGljcyBvZiBhbnl0 aGluZyBpbiB0aGUgQ1JMIG90aGVyIHRoYW4gdGhlIGVudHJ5IGl0c2VsZiwgd2hhdCB5b3Ugc2F5 IGlzIHVuYWNjZXB0YWJsZSBhbmQgcG90ZW50aWFsbHkNCiBpbnNlY3VyZS48L3NwYW4+IDxicj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA0MDgwIj4mbmJzcDs8L3NwYW4+DQo8 YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGtpeC1ib3Vu Y2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cGtpeC1ib3VuY2VzQGll dGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOlttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXTwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGI+T24gQmVoYWxmIE9mIDwvYj5SdXNzIEhv dXNsZXk8Yj48YnI+DQpTZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAyMywgMjAxMiAzOjUwIFBN PGI+PGJyPg0KVG86PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRlbmlzLnBpbmthc0BidWxs Lm5ldCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRlbmlzLnBpbmthc0BidWxsLm5ldDwv c3Bhbj48L2E+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkNjOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJRVRGIFBLSVg8Yj48YnI+DQpTdWJqZWN0 OjwvYj4gUmU6IFtwa2l4XSBFcnJhdGEgaW4gc2VjdGlvbiA1LjMgZnJvbSBSRkMgNTI4MDwvc3Bh bj4gPGJyPg0KJm5ic3A7IDxicj4NCiZuYnNwOyA8YnI+DQpJIGFncmVlIHdpdGggdGhlIHByb3Bv c2FsIHRoYXQgRGVuaXMgbWFrZXMuICZuYnNwO0kgc3VwcG9ydCBoaXMgcHJvcG9zZWQgdGV4dC4g PGJyPg0KJm5ic3A7IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoaXMgdmFsaWRh dGVzIG15IHRleHQgcHJvcG9zYWwgd2hpY2ggc3RpbGwgaXM6PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQombmJzcDsgSWYgYSBD UkwgY29udGFpbnMgYSBjcml0aWNhbCBDUkwgZW50cnkgZXh0ZW5zaW9uIHRoYXQgdGhlIGFwcGxp Y2F0aW9uIDxicj4NCiZuYnNwO2Nhbm5vdCBwcm9jZXNzLCB0aGVuIHRoZSBhcHBsaWNhdGlvbiBN VVNUIE5PVCB1c2UgdGhhdCBDUkwgZW50cnkgdG88YnI+DQombmJzcDtkZXRlcm1pbmUgdGhlIHN0 YXR1cyBvZiB0aGlzIGNlcnRpZmljYXRlJnF1b3Q7LiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Ojwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjwvc3Bhbj48YnI+ DQombmJzcDsgPGJyPg0KUnVzcyA8YnI+DQombmJzcDsgPGJyPg0KJm5ic3A7PHR0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+cGtpeCBtYWlsaW5n IGxpc3Q8L3R0Pjxicj4NCjx0dD48YSBocmVmPSJtYWlsdG86cGtpeEBpZXRmLm9yZyI+cGtpeEBp ZXRmLm9yZzwvYT48L3R0Pjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3BraXgiPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wa2l4PC9zcGFuPjwvdHQ+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AA6BA445CBFDB84785CC1C45DAAE4C7926354BE3CH1PRD0610MB393_-- From denis.pinkas@bull.net Fri Aug 31 03:14:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC4C21F8570 for ; Fri, 31 Aug 2012 03:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LKvtWMyBUWl for ; Fri, 31 Aug 2012 03:14:13 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2D621F85AE for ; Fri, 31 Aug 2012 03:14:11 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id B9EFC181CD; Fri, 31 Aug 2012 12:14:10 +0200 (CEST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: X-Disclaimed: 1 From: denis.pinkas@bull.net To: piyush@identicate.com Message-ID: Date: Fri, 31 Aug 2012 12:14:09 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2FP1 November 29, 2010 X-MIMETrack: Serialize by HTTP Server on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 31/08/2012 12:14:09, Serialize complete at 31/08/2012 12:14:10, Itemize by HTTP Server on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 31/08/2012 12:14:10, Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 31/08/2012 12:14:10 Content-Type: multipart/alternative; boundary="=_alternative 00383A57C1257A6B_=" Cc: pkix@ietf.org Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 10:14:22 -0000 --=_alternative 00383A57C1257A6B_= Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Piyush, =20 I read your arguments. However, when an ASN.1 parameter is defined in an RFC and when it is imported by another RFC, both the ASN.1 syntax *and its sema= ntics*=20 are imported. =20 RC 5280 omitted to define the semantics of Extensions independently of the = context of=20 certificates and CRLs, hence why such a definition is needed, since Extensi= ons is=20 imported and used in other RFCs, including OCSP. =20 So you are correct: changes are also required in sections 5.1.2.7 and 5.2, = so that=20 they can refer to the new proposed section “4.2. Extensions”. =20 I believe that the following argument you raised is valid: =20 A SEQUENCE MUST NOT include more than one instance of a=20 particular extension.=20 There could be scenarios outside 5280 where more than one instance of same = extensions in a sequence are useful. =20 So this sentence should be removed from the proposed new section 4.2 and mo= ved=20 to section 4.2.1. =20 Section 4.2 has been redrafted to include the case indicated by Sharon whic= h is: =20 Therefore, a critical extension in the crlEntryExtensions field of an entry= shall affect=20 only the certificate specified in that entry, unless there is a related cri= tical extension=20 in the crlExtensions field that advertises a special treatment for it.̶= 1; However, this text has been generalized since it is applicable in general a= nd not only to crlEntryExtensions. =20 Here is a new proposed text for sections 4.2 and 4.2.1: =20 The extensions field allows addition of new fields to a structure=20 without modification to the ASN.1 definition. An extension field=20 consists of an extension identifier, a criticality flag, and an=20 encoding of a data value of an ASN.1 type associated with the=20 identified extension.=20 Each extension includes an OID and an ASN.1 structure. When an=20 extension appears in a structure, the OID appears as the field e extnID and the corresponding ASN.1 DER encoded structure is the=20 value of the octet string extnValue. =20 =20 For those extensions where ordering of individual extensions within=20 the SEQUENCE is significant, the specification of those individual=20 extensions shall include the rules for the significance of the order=20 therein.=20 An extension includes the boolean critical, with a default value of=20 FALSE. The text for each extension specifies the acceptable values=20 for the critical field for implementations conforming to this=20 profile.=20 An extension marked critical in a field from a SEQUENCE or=20 from a SET OF shall only affect that SEQUENCE or that SET OF,=20 unless there is another critical extension in an upper SEQUENCE or=20 an upper SET OF which advertises a special treatment for it. In=20 such a case, the relying party must be able to process both critical=20 extensions. =20 A processing system MUST reject the content of the SEQUENCE or =20 of the SET OF where the extension appears if it encounters a critical=20 extension it does not recognize or a critical extension that contains=20 information that it cannot process.=20 =20 A non-critical extension MUST be processed if it is recognized and=20 MAY be ignored if it is not recognized.=20 Note that any extension that is flagged non-critical will cause=20 inconsistent behaviour between processing systems that will process=20 the extension and processing systems that do not recognize the=20 extension and will ignore it.=20 =20 4.2.1. Standard Extensions=20 The following sections present recommended extensions used within=20 Internet certificates and standard locations for information. =20 Communities may elect to use additional extensions; however,=20 caution ought to be exercised in adopting any critical extensions=20 in certificates that might prevent use in a general context.=20 The extensions defined for X.509 v3 certificates provide methods for=20 associating additional attributes with users or public keys and for=20 managing relationships between CAs. The X.509 v3 certificate format=20 also allows communities to define private extensions to carry=20 information unique to those communities. =20 A certificate NOT include more than one instance of a particular=20 extension. =20 Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and=20 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section=20 4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. If=20 the CA issues certificates with an empty sequence for the subject =20 field, the CA MUST support the subject alternative name extension=20 (Section 4.2.1.6). Support for the remaining extensions is OPTIONAL.=20 Conforming CAs MAY support extensions that are not identified within=20 this specification; certificate issuers are cautioned that marking=20 such extensions as critical may inhibit interoperability.=20 At a minimum, applications conforming to this profile MUST recognize=20 the following extensions: key usage (Section 4.2.1.3), certificate=20 policies (Section 4.2.1.4), subject alternative name (Section=20 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints=20 (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended=20 key usage (Section 4.2.1.12), and inhibit anyPolicy (Section=20 4.2.1.14). Here is a new proposed text for sections 5.1.2.7 and 5.2: =20 5.1.2.7. Extensions=20 This field may only appear if the version is 2 (Section 5.1.2.1). If present, this field is a sequence of one or more CRL extensions. CRL extensions are discussed in Section 5.2. 5.2. CRL Extensions The extensions field defined in section 4.2 provide a method for associa= ting additional attributes with CRLs. The v2 CRL format also allows communities to define private extensions to carry information unique to those communities. Each extension in a CRL may be designated as=20 critical or non-critical. If a CRL contains a critical CRL extension=20 that the application cannot process, then the application MUST NOT=20 use that CRL to determine the status of any certificate identified=20 in that entry. However, applications may ignore unrecognized non- critical CRL extensions. Here is a new proposed text for sections 5.3: 5.3. CRL Entry Extensions The extensions field defined in section 4.2 provide a method for associa= ting additional attributes with CRL entries. The v2 CRL format also=20 allows communities to define private CRL entry extensions to carry information unique to those communities. Each extension in a CRL entry may be designated as critical or non-critical. If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL entry to=20 determine the status of the certificate identified in that entry. =20 The following subsections present recommended extensions used within Internet CRL entries and standard locations for information. Communities may elect to use additional CRL entry extensions; however, caution should be exercised in adopting any critical CRL entry extensions in CRLs that might be used in a general context. Support for the CRL entry extensions defined in this specification is optional for conforming CRL issuers and applications. However, CRL issuers SHOULD include reason codes (Section 5.3.1) and invalidity dates (Section 5.3.2) whenever this information is available. Denis -----Piyush Jain a ‚crit : -----=20 A : Santosh Chokhani , "denis.pinkas@bull.net" , Sharon Boeyen De : Piyush Jain Date : 30/08/2012 17:39 Cc : IETF PKIX Objet : RE: [pkix] Errata in section 5.3 from RFC 5280 +1 =20 Addresses the case where a RP understands IDP but does not understand CRLIs= suers. Santosh=0F’s proposal calls it out explicitly making it clearer. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of San= tosh Chokhani Sent: Tuesday, August 28, 2012 10:45 AM To: denis.pinkas@bull.net; Sharon Boeyen Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 =20 Denis and Sharon, =20 I would propose the following: =20 a) In the penultimate sentence of the first paragraph of 5.3 replace = =0F“status of any certificate=0F” with =0F“status of the = certificate represented by the CRL entry=0F”. =20 b) A critical extension in the crlEntryExtensions field of an entry sh= all affect only the certificate specified in that entry, unless there is a = related critical extension in the crlExtensions field that advertises a spe= cial treatment for it.=0F” In order to use such CRL, the relying par= ty must be able to process both the crlEntryExtension and the related crlEx= tension.=20 =20 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of den= is.pinkas@bull.net Sent: Monday, August 27, 2012 1:20 PM To: Sharon Boeyen Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 =20 Sharon,=20 Thank you for the proposal.=20 I believe that a simplification would be possible, since we do not describe= all the features of X.509 in RFC 5280:=20 a) In the penultimate sentence of the first paragraph of 5.3 replace = =0F“status of any certificate=0F” with =0F“status of this= certificate=0F”=20 b) Add a new second paragraph in 5.3 that states =0F“Therefore, = a critical extension in the crlEntryExtensions field of an entry shall affect only the certificate specified in that entry, unless there is = a related critical extension in the crlExtensions field=20 that advertises a special treatment for it.=0F”=20 Denis=20 De : Sharon Boeyen =20 A : Russ Housley =20 Cc : IETF PKIX =20 Date : 27/08/2012 19:09=20 Objet : Re: [pkix] Errata in section 5.3 from RFC 5280=20 Envoy‚ par : pkix-bounces@ietf.org=20 I think the easiest way to clarify it would be:=20 =20 a) In the penultimate sentence of the first paragraph of 5.3 replace = =0F“status of any certificate=0F” with =0F“status of this= certificate=0F”=20 b) Add a new second paragraph in 5.3 that states =0F“If an exten= sion affects the treatment of the list (e.g., multiple CRLs need to be scan= ned to examine the entire list of revoked certificates, or an entry may rep= resent a range of certificates), then either that extension or a related ex= tension shall be indicated as critical in the crlExtensionsfield. Therefore= , a critical extension in the crlEntryExtensions field of an entry shall af= fect only the certificate specified in that entry, unless there is a relate= d critical extension in the crlExtensions field that advertises a special t= reatment for it.=0F”=20 =20 From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Monday, August 27, 2012 12:42 PM To: Sharon Boeyen Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280=20 =20 Sharon:=20 =20 Thanks for digging up those words. They support the position that I have s= tated.=20 =20 How do you believe the clarifications document should change to express thi= s point?=20 =20 Russ=20 =20 =20 On Aug 27, 2012, at 12:39 PM, Sharon Boeyen wrote:=20 Russ, I realize the RFC 5280 references the 2005 edition of X.509. However = the 2009 edition (freely available athttp://www.x500standard.com/index.php?= n=3DIg.LatestAvail ) revises this text again slightly and I think makes the= intent even clearer. It states (as part of the main text and no longer a n= ote):=20 =20 If an extension affects the treatment of the list (e.g., multiple CRLs need= to be scanned to examine the entire list of revoked certificates, or an en= try may represent a range of certificates), then either that extension or a= related extension shall be indicated as critical in the crlExtensionsfield= . Therefore, a critical extension in the crlEntryExtensions field of an ent= ry shall affect only the certificate specified in that entry, unless there = is a related critical extension in the crlExtensions field that advertises = a special treatment for it. The only example of this situation defined in t= his Specification is the certificateIssuer CRL entry extension and the rela= ted issuingDistributionPoint CRL extension when theindirectCRL Boolean from= that extension is set to TRUE.=20 =20 =20 This is clearly the case for certificateIssuer as you indicate below and as= you note below the only other 2 standard crl entry extensions are irreleva= nt as they can only ever be non-critical and affect only the single identif= ied revoked certificate. Any private extension that might be defined as a c= rlEntry extension would also have to follow that same rule to be compliant = with the base standard. I do believe the 2005 text was clear but offer this= 2009 as additional confirmation of the intent (I personally find this text= even clearer).=20 =20 Cheers,=20 Sharon=20 =20 =20 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Thursday, August 23, 2012 4:15 PM To: Santosh Chokhani Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280=20 =20 Santosh:=20 =20 =20 RFC 5280 describes three CRL Entry Extensions, and all of them come from X.= 509:=20 =20 5.3.1. Reason Code=20 5.3.2. Invalidity Date=20 5.3.3. Certificate Issuer=20 =20 The first two do not have the concern that you describe, and the third one = should only be present if the CRL includes the IssuingDistributionPoint CRL= extension, and that extension includes the indirectCRL set to TRUE. The I= ssuingDistributionPoint CRL extension must be critical. RFC 5280 says:=20 =20 The issuing distribution point is a critical CRL extension that=20 identifies the CRL distribution point and scope for a particular CRL,=20 and it indicates whether the CRL covers revocation for end entity=20 certificates only, CA certificates only, attribute certificates only,=20 or a limited set of reason codes. Although the extension is=20 critical, conforming implementations are not required to support this=20 extension. However, implementations that do not support this=20 extension MUST either treat the status of any certificate not listed=20 on this CRL as unknown or locate another CRL that does not contain=20 any unrecognized critical extensions.=20 =20 To my mind, the support for the critical IssuingDistributionPoint CRL exten= sion includes the proper support for the Certificate Issuer CRL entry exten= sion.=20 =20 Russ=20 =20 =20 On Aug 23, 2012, at 4:01 PM, Santosh Chokhani wrote:=20 Russ,=20 =20 The problem with Denis=0F’s proposal is that he wants to replace the = text of not using the CRL.=20 =20 I have cited a specific example in 5280 itself where an entry extension sco= pe goes beyond that of the entry. It potentially impacts subsequent entrie= s.=20 =20 Thus, Denis=0F’s proposal is unacceptable. If he just wanted to add = the sentence as opposed to replace, it would be fine.=20 =20 In general, unless 5280 and X.509 stated that an entry extension cannot imp= act semantics of anything in the CRL other than the entry itself, what you = say is unacceptable and potentially insecure.=20 =20 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Thursday, August 23, 2012 3:50 PM To: denis.pinkas@bull.net Cc: IETF PKIX Subject: Re: [pkix] Errata in section 5.3 from RFC 5280=20 =20 =20 I agree with the proposal that Denis makes. I support his proposed text.=20 =20 This validates my text proposal which still is:=20 If a CRL contains a critical CRL entry extension that the application=20 cannot process, then the application MUST NOT use that CRL entry to determine the status of this certificate". :=20 =20 Russ=20 =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=_alternative 00383A57C1257A6B_= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =0D
Piyush,
=0D
 
=0D
I read your arguments. However, when an ASN.1= parameter is defined in an RFC
and when it is imported by another RFC= , both the ASN.1 syntax *and its semantics*
are imported.=
=0D

 

=0D
= =  

=0D
So you are correct: changes are al= so required in sections 5.1.2.7 and 5.2, so that
they can refer to th= e new proposed section “4.2. Extensions”.
=0D

 

=0D

I believe that the following argument= you raised is valid:

=0D

 

=0D

   A SEQUENCE MUST NOT include more than one instance of a
   particular extension. <= o:p>

=0D
<= FONT face=3D"Arial,Default Sans Serif,Verdana,Arial,Helvetica,sans-serif"= >There could be scenarios outside 5280 where more than one instance of sa= me
extensions in a sequence are useful.=0D

 

=0D
So this sentence should be removed= from the proposed new section 4.2 and moved
=0D
= to section 4.2.1.
=0D

 <= /o:p>

=0D

Section 4.2 has been redraf= ted to include the case indicated by Sharon which is:

=0D

 

=0D=
Therefore, a critical extension in the crlEntryExtensions field of an entry shall affect
on= ly the certificate specified in that entry, unless there is a related cri= tical extension
in the crlExtensions fi= eld that advertises a special treatment for it.”<= /FONT>
=0D
 
=0D=
=0D<= DIV>However, this text has been generalized since it is applicable in gen= eral and not only to c= rlEntryExtensions.
=0D<= P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"> 

=0D

Here is a new proposed text for sections 4.2 and = 4.2.1:

=0D

<= o:p> 

=0D
<= SPAN style=3D"mso-spacerun: yes">   The extensions field= allows addition of new fields to a structure
   without modification to the ASN.1 definition.  A= n extension field
   consists= of an extension identifier, a criticality flag, and an
   encoding of a data value of an ASN.1 type ass= ociated with the
   identifie= d extension.

   Each exte= nsion includes an OID and an ASN.1 structure.  When an= &n= bsp;
=0D
&= nbsp;  extension appears in a structure, the OID appears as t= he field e
=0D
   extnID and the correspon= ding ASN.1 DER encoded structure is the
   value of the octet string extnValue.  
=0D

 

=0D

   For those extensions where ordering of i= ndividual extensions within
  &nbs= p;the SEQUENCE is significant, the specification of those individual
   extensions shall include the r= ules for the significance of the order
=    therein.

   = An extension includes the boolean critical, with a default value of
   FALSE.  The text for each = extension specifies the acceptable values
<= FONT face=3D"Arial,Default Sans Serif,Verdana,Arial,Helvetica,sans-serif"= >   for the critical field for implementations conforming to th= is    profile.<= FONT face=3D"Arial,Default Sans Serif,Verdana,Arial,Helvetica,sans-serif"= >&nb= sp;

   An extension = marked critical in a field from a SEQUENCE or =0D

   from a SET OF shall only affect that SEQUENCE or= that SET OF,

=0D

   unless th= ere is another critical extension in an upper SEQUENCE or

=0D

   an upper SET OF which advertises a s= pecial treatment for it.  I= n

=0D

=    such a case, the re= lying party must be able to process both critical

=0D

  extensions.

=0D

 

=0D
  = ; A processing syst= em MUST reject the content of the SEQUENCE or 
   of the SET OF where the extension appears if it encou= nters a critical
=0D
   e= xtension it does not recognize or a critical extension that contains
=0D
   information that it cannot process.
=0D

 

=0D

   A non-critical extension MUST be pro= cessed if it is recognized and 
&nb= sp; MAY be ignored if it is not recognized.

=0D

  =  Note that any extension that is flagged non-critical will cause
=    the extension and processing systems that do not recognize t= he    extension and will igno= re it.

=0D

 

=0D

4.2.1.  Standard Extensions 

 The following sections prese= nt recommended extensions used within 
  Internet certificates and standard locations for inform= ation.   

 Communities may elect to use additional exten= sions; however, 
  caut= ion ought to be exercised in adopting any critical extensions 
=   in certificates that might prevent use= in a general context. 

 The extensions defined for X.509 v3 certificates pro= vide methods for 
 associating additional attributes with users or publi= c keys and for 
 managing relationships between CAs.  The X.509 v3 = certificate format 
 also allows communities to define private extensions= to carry 
<= FONT face=3D"Arial,Default Sans Serif,Verdana,Arial,Helvetica,sans-serif"= >  information unique to those communities.

=0D

 

=0D

   A certificate NOT include = more than one instance of a particular

=0D   extension.    <= BR>
  Conforming CAs MU= ST support key identifiers (Sections 4.2.1.1 and =
  4.2.1.2), basic cons= traints (Section 4.2.1.9), key usage (Section 
  4.2.1.3), and certificate p= olicies (Section 4.2.1.4) extensions.  If 
  the CA issues certificates= with an empty sequence for the subject   =
<= /SPAN>    field, the CA MUST s= upport the subject alternative name extension 
=   (Section 4.2.1.6).  Suppor= t for the remaining extensions is OPTIONAL. 
<= /FONT>  Conforming CAs MAY suppor= t extensions that are not identified within 
  this specification; certifica= te issuers are cautioned that marking 
=   such extensions as critical may= inhibit interoperability. 

=    At a mi= nimum, applications conforming to this profile MUST recognize
   th= e following extensions: key usage (Section 4.2.1.3), certificate
   =
   4.2.1.6), basic constraints (Section 4.2.1.9), name constraints<= FONT size=3D3>
   = ;(Section 4.2.1.10), policy constraints (Section 4.2.1.11), exte= nded
  =  key usage (Section 4.2.1.12), and inhibit anyPolicy (Secti= on
 = ;  4.2.1.14).

=0D

Here is a new proposed text for <= SPAN lang=3DEN-US style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Arial; mso-ansi-= language: EN-US">sections 5.1.2.7 and 5.2:

=0D

=0D

 
5.1.2.7.  Extensi= ons =0D

=0D

   This field may= only appear if the version is 2 (Section 5.1.2.1).  If
 &nb= sp; present, this field is a sequence of one or more CRL extensions. = ; CRL
   extensions are discussed in Section 5.2.

= =0D

5.2.  CRL Extensions

=0D

   The extensions field defined in section 4.2 pro= vide a method for associating
   additional attributes with = CRLs.  The v2 CRL format also allows
   communities to = define private extensions to carry information unique
   to = those communities.  Each extension in a CRL may be designated as    critical or non-critical. If a CRL contains a critical CRL = extension
   that the application cannot process, then the = application MUST NOT
   use that CRL to determine the statu= s of any certificate identified
   in that entry.  How= ever, applications may ignore unrecognized non-
   critical = CRL extensions.

=0D

Here is a new = proposed text for sections 5.3:

=0D

5.3.  CRL Entry Extensions

=0D

=    The extensions field defined in section 4.2 provide a method= for associating
   additional attributes with CRL entries.&= nbsp; The v2 CRL format also
   allows communities to defin= e private CRL entry extensions to carry
   information uniqu= e to those communities.  Each extension in a CRL
   ent= ry may be designated as critical or non-critical.  If a CRL
 = ;  contains a critical CRL entry extension that the application cann= ot
   process, then the application MUST NOT use that CRL en= try to
   determine the status of the certificate identifie= d in that entry.
  
   The following subsectio= ns present recommended extensions used within
   Internet CR= L entries and standard locations for information.
   Communi= ties may elect to use additional CRL entry extensions;
   ho= wever, caution should be exercised in adopting any critical CRL
 =   entry extensions in CRLs that might be used in a general context.<= /FONT>

=0D

   S= upport for the CRL entry extensions defined in this specification is
&= nbsp;  optional for conforming CRL issuers and applications.  H= owever, CRL
   issuers SHOULD include reason codes (Section = 5.3.1) and invalidity
   dates (Section 5.3.2) whenever this= information is available.

=0D

Denis

-----Piyush Jain <piyush@identicate.com> a =E9crit : --= ---

=0D
=0D
A : Santosh Chokhani <SChokhani@cygnacom.com>, "denis.pinkas= @bull.net" <denis.pinkas@bull.net>, Sharon Boeyen <sharon.boeyen= @entrust.com>
De : Piyush Jain <piyush@identicate.com>
Dat= e : 30/08/2012 17:39
Cc : IETF PKIX <pkix@ietf.org>
Objet : R= E: [pkix] Errata in section 5.3 from RFC 5280

=0D=
=0D

+1

=0D

 =

=0D

Addresses the case where a RP und= erstands IDP but does not understand CRLIssuers.

=0D=

Santosh’s proposal calls it out ex= plicitly making it clearer.

=0D
=0D
=0D
=0D

From: pkix-bo= unces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Santosh= Chokhani
Sent: Tuesday, August 28, 2012 10:45 AM
To:= denis.pinkas@bull.net; Sharon Boeyen
Cc: IETF PKIX
Subje= ct: Re: [pkix] Errata in section 5.3 from RFC 5280<= /P>

=0D

 

=0D

Denis and Sharon,

=0D

 

=0D

I would propose the following:

=0D

 

=0D

a)      <= SPAN style=3D"FONT-SIZE: 9pt; COLOR: #004080; FONT-FAMILY: 'Arial','sans-= serif'">In the penultimate sentence of the first paragraph of 5.3 replace= “status of any certificate” with “status of the certif= icate represented by the CRL entry”.

=0D

 

=0D

b)      A critical extension in the crlEntryExtensions field= of an entry shall affect only the certificate specified in that entry, u= nless there is a related critical extension in the crlExtensions f= ield that advertises a special treatment for it.”  In order to= use such CRL, the relying party must be able to process both the crlE= ntryExtension and the related crlExtension.

=0D

 

=0D

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net
Sent:= Monday, August 27, 2012 1:20 PM
To: Sharon Boeyen
Cc= : IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from = RFC 5280

=0D

 =0D

Sharon,

Thank you for the proposal. <= BR>
I believe that a simplification would be possible, since we do not descr= ibe all the features of  X.509 in RFC 5280:

b)     &= nbsp;Add a new second paragraph in 5.3 that states “Therefore, a critical extension in the <= /I>crlEntryExtensions field of an entryshall affect only the certificate specified in that entry, unless there = is a related critical extension in the crlExtensions field
tha= t advertises a special treatment for it.”

Denis=



De :        Sharon Boey= en <sharon.boeyen@entrust= .com>
A :        = Russ = Housley <housley@vigilsec.com<= /A>>
Cc :        IETF= PKIX <pkix@ietf.org> <= BR>Date :        27/08/2012 19:09=
Objet :        Re: [pkix] Errata in= section 5.3 from RFC 5280
Envoy=E9 par :   &n= bsp;    pkix-bounces= @ietf.org

=0D
=0D
=0D
=0D




I think the easiest way to c= larify it would be:
 
a)=      In the penultimate sentence of the first paragraph o= f 5.3 replace “status of any certificate” with “status = of this certificate”
b)      = Add a new second paragraph in 5.3 that states “If an extension affects the treatment of the list (e= .g., multiple CRLs need to be scanned to examine the entire list of revok= ed certificates, or an entry may represent a range of certificates), then= either that extension or a related extension shall be indicated as criti= cal in the crlExtensionsfield. Therefore, a critical extension in the= crlEntryExtensions field of an= entry shall affect only the certificate specified in that entry, unless = there is a related critical extension in the crlExtensions field t= hat advertises a special treatment for it.”
 
From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Monday= , August 27, 2012 12:42 PM
To: Sharon Boeyen
Cc: IETF= PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280
 
Sharon:
 
Thanks for digging up those w= ords.  They support the position that I have stated.
 
= How do you believe the clarifications document should change to express t= his point?
 
Russ
 
 
On Aug 27, 2012,= at 12:39 PM, Sharon Boeyen wrote:


Russ, I realiz= e the RFC 5280 references the 2005 edition of X.509. However the 2009 edi= tion (freely available athttp://www.x500standard.com/index.php?n=3DIg.Late= stAvail ) revises this text again slightly and I t= hink makes the intent even clearer. It states (as part of the main text a= nd no longer a note):
 
If an extension affects the treatment of the list (e.= g., multiple CRLs need to be scanned to examine the entire list of revoke= d certificates, or an entry may represent a range of certificates), then = either that extension or a related extension shall be indicated as critic= al in the crlExtensionsfield. Therefore, a critical extension in the <= /I>crlEntryExtensions field of an entry shall affect o= nly the certificate specified in that entry, unless there is a related cr= itical extension in the crlExtensions field that advertises a spec= ial treatment for it. The only example of this situation defined in this = Specification is the certificateIssuer= CRL entry extension and the related issuingDistributionPoint CRL extension when theindirectCRL Boolean from = that extension is set to TRUE.
 
<= SPAN style=3D"FONT-SIZE: 10pt; COLOR: #004080; FONT-FAMILY: 'Calibri','sa= ns-serif'"> 
This is clearly the case for cer= tificateIssuer as you indicate below and as you note below the only other= 2 standard crl entry extensions are irrelevant as they can only ever be = non-critical and affect only the single identified revoked certificate. A= ny private extension that might be defined as a crlEntry extension would = also have to follow that same rule to be compliant with the base standard= . I do believe the 2005 text was clear but offer this 2009 as additional = confirmation of the intent (I personally find this text even clearer).
 
Cheers,
Sharon
 
&nbs= p;
From: <= SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">pkix-b= ounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley=
Sent: Thursday, August 23, 2012 4:15 PM
To: Santosh Cho= khani
Cc: IETF PKIX
Subject: Re: [pkix] Errata in sec= tion 5.3 from RFC 5280
 
Santosh:
 
&nbs= p;
RFC 5280 describes three CRL Entry Extensions, and all of them com= e from X.509:
 
            5.= 3.1.  Reason Code
            5.3.= 2.  Invalidity Date
            5.= 3.3.  Certificate Issuer
 
The first two do not have th= e concern that you describe, and the third one should only be present if = the CRL includes the IssuingDistributionPoint CRL extension, and that ext= ension includes the indirectCRL set to TRUE.  The IssuingDistributio= nPoint CRL extension must be critical.  RFC 5280 says:
     The issuing distribution point is a critical CRL extension= that
   identifies the CRL distribution point and scope fo= r a particular CRL,
   and it indicates whether the CRL cov= ers revocation for end entity
   certificates only, CA cert= ificates only, attribute certificates only,
   or a limited= set of reason codes.  Although the extension is
   cr= itical, conforming implementations are not required to support this
&= nbsp;  extension.  However, implementations that do not support= this
   extension MUST either treat the status of any cert= ificate not listed
   on this CRL as unknown or locate anot= her CRL that does not contain
   any unrecognized critical = extensions.
 
To my mind, the support for the critical Issui= ngDistributionPoint CRL extension includes the proper support for the Cer= tificate Issuer CRL entry extension.
 
Russ
 
&= nbsp;
On Aug 23, 2012, at 4:01 PM, Santosh Chokhani wrote:


Russ,
 
The problem with Denis’s proposal is that he wants to replace the = text of not using the CRL.
 
I have cited a specific example in 5280 itself where an entry extens= ion scope goes beyond that of the entry.  It potentially impacts sub= sequent entries.
 
Thus,= Denis’s proposal is unacceptable.  If he just wanted to add t= he sentence as opposed to replace, it would be fine.
In general, unless 5280 and X.509 stated t= hat an entry extension cannot impact semantics of anything in the CRL oth= er than the entry itself, what you say is unacceptable and potentially in= secure.
 
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] = On Behalf Of Russ Housley
Sent: Thursday, August 23, 2012 3= :50 PM
To: denis.pin= kas@bull.net
Cc: IETF PKIX
Subject: Re: [pkix= ] Errata in section 5.3 from RFC 5280
 
 
I = agree with the proposal that Denis makes.  I support his proposed te= xt.
 
This validates my text proposal which still is:

  = If a CRL contains a critical CRL entry extension that the application  cannot process, then the application MUST NOT use that CRL entry t= o
 determine the status of this certificate". :
 =
Russ
 
 ______= _________________________________________
pkix mailing listpkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

=0D
 --=_alternative 00383A57C1257A6B_=-- From denis.pinkas@bull.net Fri Aug 31 03:16:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A0F21F85AE for ; Fri, 31 Aug 2012 03:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RTOZLBgoUJV for ; Fri, 31 Aug 2012 03:16:45 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3554421F85AA for ; Fri, 31 Aug 2012 03:16:45 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 89C81181FB for ; Fri, 31 Aug 2012 12:16:44 +0200 (CEST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: X-Disclaimed: 1 From: denis.pinkas@bull.net To: "IETF PKIX" Message-ID: Date: Fri, 31 Aug 2012 12:16:44 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2FP1 November 29, 2010 X-MIMETrack: Serialize by HTTP Server on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 31/08/2012 12:16:44, Serialize complete at 31/08/2012 12:16:44, Itemize by HTTP Server on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 31/08/2012 12:16:44, Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 31/08/2012 12:16:44 Content-Type: multipart/alternative; boundary="=_alternative 003876CCC1257A6B_=" Subject: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 10:16:46 -0000 --=_alternative 003876CCC1257A6B_= Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 A new version of I-D, draft-pinkas-2560bis-certinfo-00.txt has been successfully submitted by Denis Pinkas and posted=20 to the IETF repository. Filename: draft-pinkas-2560bis-certinfo Revision: 00 Title: CertInfo single response extension Update to OCSP < draft-pinkas-256= 0bis-certinfo-00.txt > Creation date: 2012-08-31 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-c= ertinfo-00.txt Status: http://datatracker.ietf.org/doc/draft-pinkas-2560bis-certi= nfo Htmlized: http://tools.ietf.org/html/draft-pinkas-2560bis-certinfo-00 Abstract: OCSP [RFC2560] has been designed to allow an OCSP server to use any kind of trustable information to answer to a client varying from CRLs to an access to a database of issued certificates. In its original version, OCSP does not allow taking full advantage of an access to a database of issued certificates. When a database of issued certificates is used by an OCSP server, this document explains how the OCSP server shall respond and how OCSP clients shall react. The proposal is intended to update 2560bis. It defines a new single extension in a single response, called certInfo. The extension is non critical. The meaning of "good", "revoked" and "unknown" are unchanged. = =20 The IETF Secretariat --=_alternative 003876CCC1257A6B_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
=0D

A new v= ersion of I-D, draft-pinkas-2560bis-certinfo-00.txt
has been successfull= y submitted by Denis Pinkas and posted
to the IETF repository.

F= ilename: draft-pinkas-2560bis-certinfo
Revision: 00
Title: CertInfo s= ingle response extension Update to OCSP < draft-pinkas-2560bis-certinfo-= 00.txt >
Creation date: 2012-08-31
WG ID: Individual SubmissionNumber of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-certinfo-00.t= xt
Status:          http://datatracker.ietf.= org/doc/draft-pinkas-2560bis-certinfo
Htmlized:      =  http://tools.ietf.org/html/draft-pinkas-2560bis-certinfo-00

= Abstract:
   OCSP [RFC2560] has been designed to allow an OCSP= server to use
   any kind of trustable information to answer = to a client varying
   from CRLs to an access to a database of= issued certificates.

   In its original version, OCSP doe= s not allow taking full advantage
   of an access to a databas= e of issued certificates.

   When a database of issued cer= tificates is used by an OCSP server,
   this document explains= how the OCSP server shall respond and how
   OCSP clients sha= ll react.

   The proposal is intended to update 2560bis. I= t defines a new single
   extension in a single response, call= ed certInfo.  The extension is
   non critical.  The= meaning of "good", "revoked" and "unknown" are
   unchanged.&= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;    

The IETF Secretariat
=0D
 --=_alternative 003876CCC1257A6B_=-- From eabalea@gmail.com Fri Aug 31 05:10:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A05721F856C for ; Fri, 31 Aug 2012 05:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Whkvj85EiDCf for ; Fri, 31 Aug 2012 05:10:42 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0E621F8568 for ; Fri, 31 Aug 2012 05:10:42 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3633910vcb.31 for ; Fri, 31 Aug 2012 05:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y401a2SnZnUKvEatqRfvINrYkQF91lR46K8iQ+fw36M=; b=z154NBq2h0Sy16icvLQDvFoDAb4jrtClJPS4qTGsLjEHZzsIPTLwR7xbLZA/Xp1CYs ObyD/Gn5g6Vc3JJ6COcrpdXDqwGf80AmylYfZZ43AKd7OGUbclYywaUTdLDjeV07wJ8E bebxDPm/Js1vNr4eS06Z3JxJxpt9cuO1HbShtTHyi5cs+7g78ERlCzr2b9XajnHpMFqH ZjxUpEGVrlZRCsA050pRDULTUZkqh+HezJMVPeqMpxQyWa7LkGt/mHuDLMNcRMLiKfB3 9PHxyRc0iJcCYyZuGg1uC3Rqu3FdbgXyPGUCPdBcA3xfaFXryWXKoE2adCaTJUK7BFXD C9jA== MIME-Version: 1.0 Received: by 10.52.175.130 with SMTP id ca2mr4649117vdc.112.1346415041421; Fri, 31 Aug 2012 05:10:41 -0700 (PDT) Received: by 10.59.5.3 with HTTP; Fri, 31 Aug 2012 05:10:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 31 Aug 2012 14:10:41 +0200 Message-ID: From: Erwann Abalea To: denis.pinkas@bull.net Content-Type: text/plain; charset=UTF-8 Cc: IETF PKIX Subject: Re: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 12:10:47 -0000 2012/8/31 : [...] > Abstract: > OCSP [RFC2560] has been designed to allow an OCSP server to use > any kind of trustable information to answer to a client varying > from CRLs to an access to a database of issued certificates. > > In its original version, OCSP does not allow taking full advantage > of an access to a database of issued certificates. Really? OCSP allows to access a database of issued certificates, but does not allow it? At the same time? -- Erwann. From piyush@identicate.com Fri Aug 31 07:37:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AEE21F846C for ; Fri, 31 Aug 2012 07:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BBORJ-eoYMR for ; Fri, 31 Aug 2012 07:37:47 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id F1A0021F842A for ; Fri, 31 Aug 2012 07:37:46 -0700 (PDT) Received: from mail94-am1-R.bigfish.com (10.3.201.228) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 31 Aug 2012 14:37:44 +0000 Received: from mail94-am1 (localhost [127.0.0.1]) by mail94-am1-R.bigfish.com (Postfix) with ESMTP id 6A29036018D; Fri, 31 Aug 2012 14:37:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.229; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0610HT004.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: PS-28(zzbb2dI9371I542M1432Izz1202hzz8275ch1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail94-am1: domain of identicate.com designates 157.56.244.229 as permitted sender) client-ip=157.56.244.229; envelope-from=piyush@identicate.com; helo=CH1PRD0610HT004.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail94-am1 (localhost.localdomain [127.0.0.1]) by mail94-am1 (MessageSwitch) id 1346423861983170_26225; Fri, 31 Aug 2012 14:37:41 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.250]) by mail94-am1.bigfish.com (Postfix) with ESMTP id EE3A9A0046; Fri, 31 Aug 2012 14:37:41 +0000 (UTC) Received: from CH1PRD0610HT004.namprd06.prod.outlook.com (157.56.244.229) by AM1EHSMHS018.bigfish.com (10.3.207.156) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 31 Aug 2012 14:37:41 +0000 Received: from CH1PRD0610MB393.namprd06.prod.outlook.com ([169.254.11.123]) by CH1PRD0610HT004.namprd06.prod.outlook.com ([10.255.151.39]) with mapi id 14.16.0175.005; Fri, 31 Aug 2012 14:37:41 +0000 From: Piyush Jain To: Erwann Abalea , "denis.pinkas@bull.net" Thread-Topic: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00 Thread-Index: AQHNh3HRGjAx3GlFh0q0pj39NL6+1pdz/KTA Date: Fri, 31 Aug 2012 14:37:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.25.128.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: identicate.com Cc: IETF PKIX Subject: Re: [pkix] New version Notification for draft-pinkas-2560bis-certinfo-00 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 14:37:48 -0000 Takes "full advantage" in the new version, did not take "full advantage" in= the original version :). > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Erwann Abalea > Sent: Friday, August 31, 2012 5:11 AM > To: denis.pinkas@bull.net > Cc: IETF PKIX > Subject: Re: [pkix] New version Notification for draft-pinkas-2560bis- > certinfo-00 >=20 > 2012/8/31 : > [...] > > Abstract: > > OCSP [RFC2560] has been designed to allow an OCSP server to use > > any kind of trustable information to answer to a client varying > > from CRLs to an access to a database of issued certificates. > > > > In its original version, OCSP does not allow taking full advantage > > of an access to a database of issued certificates. >=20 > Really? OCSP allows to access a database of issued certificates, but does= not > allow it? At the same time? >=20 > -- > Erwann. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix