From Johannes.Merkle@secunet.com Mon Feb 4 09:07:27 2013 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 61D1221F8534 for ; Mon, 4 Feb 2013 09:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 nD9bM7ABqZjU for ; Mon, 4 Feb 2013 09:07:27 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id C6DB321F8526 for ; Mon, 4 Feb 2013 09:07:26 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 4163C1A0078 for ; Mon, 4 Feb 2013 18:07:24 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 37BEC1A0076 for ; Mon, 4 Feb 2013 18:07:23 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Feb 2013 18:07:23 +0100 Message-ID: <510FEACA.6090708@secunet.com> Date: Mon, 04 Feb 2013 18:07:22 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: <201301291706.r0TH6Ecp026364@mail.nbusr.sk> <51080D8A.5000201@bull.net> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Feb 2013 17:07:23.0076 (UTC) FILETIME=[195A7040:01CE02FA] Subject: Re: [pkix] 2560bis draft 12 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, 04 Feb 2013 17:07:27 -0000 > The French legislation you quoted earlier is clearly not a problem here, as I pointed out before (Nov 8 & 9). What other > regulations do you have in mind? To be able to asses this we need to look at the letter of the law. In my recollection, > the German law is not worded in such a way to prevent this either (indeed, I believe that text we are writing makes a > good foundation for solving some of the requirements the German law does have). > You can safely disregard the German electronic signature legislation in your discussion on how to deal with requests for non-issued certificates. In the context of qualified certificates, German regulation (de-facto) requires to return status "unknown" in this case and the implemented basis (in the niche market for qualified certificates) is so strongly established that any new approach (e.g. revoked" with reason code "onhold") is unlikely to be supported. -- Johannes From mrex@sap.com Mon Feb 4 17:20:46 2013 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 BAAD421F8B3F for ; Mon, 4 Feb 2013 17:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.222 X-Spam-Level: X-Spam-Status: No, score=-11.222 tagged_above=-999 required=5 tests=[AWL=1.027, BAYES_00=-2.599, GB_I_LETTER=-2, 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 I5JoSLE2TGjH for ; Mon, 4 Feb 2013 17:20:46 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id EC95321F8B47 for ; Mon, 4 Feb 2013 17:20:45 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r151Kh7I028056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Feb 2013 02:20:43 +0100 (MET) In-Reply-To: <510FEACA.6090708@secunet.com> To: Johannes Merkle Date: Tue, 5 Feb 2013 02:20:43 +0100 (CET) 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: <20130205012043.C306A1A4FD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] 2560bis draft 12 posted 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, 05 Feb 2013 01:20:46 -0000 Johannes Merkle wrote: > > > The French legislation you quoted earlier is clearly not a > > problem here, as I pointed out before (Nov 8 & 9). What other > > regulations do you have in mind? To be able to asses this we > > need to look at the letter of the law. In my recollection, > > the German law is not worded in such a way to prevent this > > either (indeed, I believe that text we are writing makes a > > good foundation for solving some of the requirements the > > German law does have). > > > You can safely disregard the German electronic signature legislation > in your discussion on how to deal with requests for non-issued > certificates. In the context of qualified certificates, German > regulation (de-facto) requires to return status "unknown" in this > case and the implemented basis (in the niche market for qualified > certificates) is so strongly established that any new approach > (e.g. revoked" with reason code "onhold") is unlikely to be supported. What the installed base does, what implementations understand, and what other responses will not have the detrimental effect of certs getting inappropriately accepted, are all seperate things. Could you please point me to the particular German regulation documents that you believe would be incompatible with the 2560bis change in that things would no longer work? -Martin From Johannes.Merkle@secunet.com Tue Feb 5 04:22:07 2013 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 F08D821F8804 for ; Tue, 5 Feb 2013 04:22:06 -0800 (PST) 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=[AWL=-1.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 pwyTB3OIlf3J for ; Tue, 5 Feb 2013 04:22:04 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1A53021F8691 for ; Tue, 5 Feb 2013 04:22:03 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 1AA2E1A006F; Tue, 5 Feb 2013 13:22:00 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 348891A006C; Tue, 5 Feb 2013 13:21:58 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Feb 2013 13:21:57 +0100 Message-ID: <5110F965.4070903@secunet.com> Date: Tue, 05 Feb 2013 13:21:57 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mrex@sap.com References: <20130205012043.C306A1A4FD@ld9781.wdf.sap.corp> In-Reply-To: <20130205012043.C306A1A4FD@ld9781.wdf.sap.corp> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Feb 2013 12:21:58.0037 (UTC) FILETIME=[64729C50:01CE039B] Cc: pkix@ietf.org Subject: Re: [pkix] 2560bis draft 12 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: Tue, 05 Feb 2013 12:22:07 -0000 >> You can safely disregard the German electronic signature legislation >> in your discussion on how to deal with requests for non-issued >> certificates. In the context of qualified certificates, German >> regulation (de-facto) requires to return status "unknown" in this >> case and the implemented basis (in the niche market for qualified >> certificates) is so strongly established that any new approach >> (e.g. revoked" with reason code "onhold") is unlikely to be supported. > > > What the installed base does, what implementations understand, > and what other responses will not have the detrimental effect > of certs getting inappropriately accepted, are all seperate things. This is actually a closed world governed by its own rules: According to the electronic signature act §17 (4), for all OCSP responders and client software used to verify qualified certificates, compliance with the requirements of the act must either be confirmed by an authorized body or be formally declared by the manufacturer. The supervising authority maintains a list of products (incl. OCSP responders and client software) for which such a confirmation or declaration has been filed: http://www.bundesnetzagentur.de/cln_1931/EN/Areas/ElectronicSignature/Publications/Products/Products_node.html By virtue of the requirement to use only software conforming to the electronic signature act, OCSP clients and responders exhibit a specific behavior that ensures that they can inter-operate with each other although this behavior may go beyond (but does not violate) RFC 2560. > > Could you please point me to the particular German regulation documents > that you believe would be incompatible with the 2560bis change in that > things would no longer work? > I didn't mean to claim any incompatibility of German regulation with RFC 2560bis. I only wanted to convey that German regulation has developed other means to deal with non-issued certificates, precisely, to return status "unknown", and this makes adoption of the RFC 2560bis approach unlikely. However, as far as I have understood RFC 2560bis the German solution (status unknown) is not prohibited by RFC 2560bis, and vice-versa, the RFC 2560bis approach does not contradict German regulation nor does it result in undesired results with German OCSP clients. Now for the specific requirements: First of all, I wrote "de-facto", which means that there is no clear written requirement. But in practice, bodies confirming conformance of OCSP responders to the electronic signature act as well as the supervising authority will not accept an OCSP responder software returning "good" for non-issued certificates. The reason is that §15 (3) of the electronic signature ordinance requires certificate validation services to assert not only the revocation status of the certificate but also its existence in the CA database. As a consequence, compliant OCSP responders must base their assertions not on a CRL but on the (replicated) CA database, hence, the the status "unknown" can be safely used to assert non-issuance of a certificate. I say "safely" because OCSP clients to be used with qualified certificates in Germany originate from the same closed world and have, thus, been developed based on the same requirements and assumptions. BTW: Another special feature of OCSP responders for which compliance with the signature act has been declared or confirmed is that they will actually attest the existence of "good" certificates by an extension CertHash specified in the Common PKI standard (http://www.t7ev.org/en/common-pki.html). This standard specifically targets compliance with the German electronic signature act (part 9 defines a specific profile for this) and has been widely adopted by applications (also clients) claiming conformance with the regulation. It is important to note, that in the "German world", the OCSP-responders obtain their certificates not from the corresponding CA but from the CA super-ordinated to that - with the only exception being the root CA. Thus, compromise of a 2nd level CA does not compromise its OCSP responder and, hence, clients can still trust the assertions of the OCSP responder. This was designed to circumvent the trust model problems pointed out by Piyush of authorized responders also asserting issuance or non-issuance of certificates. -- Johannes From stefan@aaa-sec.com Thu Feb 7 06:54:50 2013 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 2657E21F855D for ; Thu, 7 Feb 2013 06:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.493 X-Spam-Level: X-Spam-Status: No, score=-101.493 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 oRzCQL680Imj for ; Thu, 7 Feb 2013 06:54:49 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6A621F8A0C for ; Thu, 7 Feb 2013 06:54:48 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 5FEFF378AC0 for ; Thu, 7 Feb 2013 15:54:46 +0100 (CET) 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 kFiaM8nsS7id for ; Thu, 7 Feb 2013 15:54:45 +0100 (CET) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id DB455378AB7 for ; Thu, 7 Feb 2013 15:54:45 +0100 (CET) Received: (qmail 36447 invoked from network); 7 Feb 2013 14:54:45 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.201]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 Feb 2013 14:54:45 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Thu, 07 Feb 2013 15:54:39 +0100 From: Stefan Santesson To: Johannes Merkle , Message-ID: Thread-Topic: [pkix] 2560bis draft 12 posted In-Reply-To: <5110F965.4070903@secunet.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] 2560bis draft 12 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, 07 Feb 2013 14:54:50 -0000 Thanks for the explanations Johannes. As far as I can tell there is not contradiction between RFC2560bis and the german law, not even implementation of the "renoked" option and the new extension, even though it may not happen i practice for reason you explained. /Stefan On 2/5/13 1:21 PM, "Johannes Merkle" wrote: > >>> You can safely disregard the German electronic signature legislation >>> in your discussion on how to deal with requests for non-issued >>> certificates. In the context of qualified certificates, German >>> regulation (de-facto) requires to return status "unknown" in this >>> case and the implemented basis (in the niche market for qualified >>> certificates) is so strongly established that any new approach >>> (e.g. revoked" with reason code "onhold") is unlikely to be supported. >>=20 >>=20 >> What the installed base does, what implementations understand, >> and what other responses will not have the detrimental effect >> of certs getting inappropriately accepted, are all seperate things. > >This is actually a closed world governed by its own rules: According to >the electronic signature act =A717 (4), for all >OCSP responders and client software used to verify qualified >certificates, compliance with the requirements of the act >must either be confirmed by an authorized body or be formally declared by >the manufacturer. The supervising authority >maintains a list of products (incl. OCSP responders and client software) >for which such a confirmation or declaration >has been filed: >http://www.bundesnetzagentur.de/cln_1931/EN/Areas/ElectronicSignature/Publ >ications/Products/Products_node.html > >By virtue of the requirement to use only software conforming to the >electronic signature act, OCSP clients and >responders exhibit a specific behavior that ensures that they can >inter-operate with each other although this behavior >may go beyond (but does not violate) RFC 2560. > > >>=20 >> Could you please point me to the particular German regulation documents >> that you believe would be incompatible with the 2560bis change in that >> things would no longer work? >>=20 > >I didn't mean to claim any incompatibility of German regulation with RFC >2560bis. I only wanted to convey that German >regulation has developed other means to deal with non-issued >certificates, precisely, to return status "unknown", and >this makes adoption of the RFC 2560bis approach unlikely. However, as far >as I have understood RFC 2560bis the German >solution (status unknown) is not prohibited by RFC 2560bis, and >vice-versa, the RFC 2560bis approach does not contradict >German regulation nor does it result in undesired results with German >OCSP clients. > >Now for the specific requirements: First of all, I wrote "de-facto", >which means that there is no clear written >requirement. But in practice, bodies confirming conformance of OCSP >responders to the electronic signature act as well >as the supervising authority will not accept an OCSP responder software >returning "good" for non-issued certificates. >The reason is that =A715 (3) of the electronic signature ordinance requires >certificate validation services to assert not >only the revocation status of the certificate but also its existence in >the CA database. As a consequence, compliant >OCSP responders must base their assertions not on a CRL but on the >(replicated) CA database, hence, the the status >"unknown" can be safely used to assert non-issuance of a certificate. I >say "safely" because OCSP clients to be used >with qualified certificates in Germany originate from the same closed >world and have, thus, been developed based on the >same requirements and assumptions. > >BTW: Another special feature of OCSP responders for which compliance with >the signature act has been declared or >confirmed is that they will actually attest the existence of "good" >certificates by an extension CertHash specified in >the Common PKI standard (http://www.t7ev.org/en/common-pki.html). This >standard specifically targets compliance with the >German electronic signature act (part 9 defines a specific profile for >this) and has been widely adopted by applications >(also clients) claiming conformance with the regulation. > >It is important to note, that in the "German world", the OCSP-responders >obtain their certificates not from the >corresponding CA but from the CA super-ordinated to that - with the only >exception being the root CA. Thus, compromise >of a 2nd level CA does not compromise its OCSP responder and, hence, >clients can still trust the assertions of the OCSP >responder. This was designed to circumvent the trust model problems >pointed out by Piyush of authorized responders also >asserting issuance or non-issuance of certificates. > >--=20 >Johannes >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Mon Feb 11 06:18:44 2013 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 6254B21F88E3 for ; Mon, 11 Feb 2013 06:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 g8yUJFlQfqtJ for ; Mon, 11 Feb 2013 06:18:44 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1768321F88FC for ; Mon, 11 Feb 2013 06:18:35 -0800 (PST) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 151FD1D157; Mon, 11 Feb 2013 15:18:34 +0100 (CET) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2013021115182376-17398 ; Mon, 11 Feb 2013 15:18:23 +0100 Message-ID: <5118FDAB.5080804@bull.net> Date: Mon, 11 Feb 2013 15:18:19 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/02/2013 15:18:33, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/02/2013 15:18:33, Serialize complete at 11/02/2013 15:18:33 Content-Type: multipart/alternative; boundary="------------030806070903090303090301" Cc: pkix Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC 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, 11 Feb 2013 14:18:44 -0000 This is a multi-part message in MIME format. --------------030806070903090303090301 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Stefan, I have finally reviewed your disposition of comments. I have used draft 13. I will not address the comments in sequence, but I will consider four categories: *Category 1)*Some comments which seem to be solved. Yes indeed, they may be a few of them ! *Category 2)*Some comments which might possibly be solved at the WG level. *Category 3)*Some comments that I will address at the IETF last call level, rather than the WG last call level, since I disagree that it is "new ways to say the same thing" and it is likely to be a waste of time for both of us to argue again at the WG level (these comments are commented as "not broken"). *Category 4)*Some typos and editorials found while reading draft 13. *CATEGORY 1* *Comment 4*(was editorial). *Comment 5.* ** *Comment 6. * *Comment 19*. Solved, since *"unknown"*seems now to be also allowed for non-issued certificates (even if the OCSP responder is using a direct access to the certificate database). See comment 8. *Comment 13*: Acceptable, since the text uses *"MAY".* *Comment 18. * *Comment 22.* *Comment 23.* *Comment 28.* *CATEGORY 1* *Comment 8*: You have changed the meaning of the revoked state in a way that is not what I requested. The original text was: *The "revoked" state indicates that the certificate has been revoked* *(either permanantly or temporarily (on hold)).* The new text is: ** * The "revoked" state indicates that the certificate has been revoked* * either permanently or temporarily on hold (i.e. the revocation reason* * is certificateHold).* By doing this, you do not allow any other case in the future to have a temporary revocation: "*temporarily on hold"** *is not the same as*"**temporarily revoked"**.* I propose the following rewording: *The "revoked" state indicates that the certificate has been revoked * * either permanently or temporarily (e.g. placed on hold).* The way the text from draft 13 is now written seems to allow using either *"unknown"*or *"revoked"*for non-issued certificates. If this is the intent, then the good news is that this does not come anymore into conflict with the French rules which apply for the Administration since OCSP responders from CAs used by the French Ministries having a direct access to the database of issued certificates will be able to use *"unknown*", rather than *"revoked"*and the reason code *"onhold".* However, the current text is still mandating the use of *Extended Revoked Definition*, but the rational for its need it is very poor. As I have said on the PKIX list, the fact that the revocation date is January 1rst, 1970 is fully sufficient to know that we are in that very special case, and you have not provided a rational to say the contrary. So we could get rid of it, ... but the text from section 4.4.8 states: * This extension MAY be present in other responses to signal that the* * responder implements the extended revoked definition in section 2.2.* I have difficulties to understand what is really meant there ("other responses" ?), since the text states: * This extension indicates that the responder supports the extended* * definition of the "revoked" status to also include non-issued* * certificates according to section 2.2.* Since both "unknown" and revoked" can be used, it would be desirable to be able to include the same extension in both cases, but in that case that extension should be renamed. I would propose to rename it: "*non-issued certificate*" which means that the associated CA has no record of ever having issued a certificate with the certificate serial number in the request (I still consider it as unnecessary in the case of "revoked", but it would be very useful in the case of "unknown"). Of course, the text from section 4.4.8 would need to be revised. I propose the following: *4.4.8 Non-issued certificate extension* * * * This extension MUST be included in the OCSP response when the OCSP* * responder knows that the CA identified in the request has no record* * of ever having issued a certificate with the certificate serial* * number indicated in the request.* * * * Clients do not have to parse this extension in order to determine* * the status of certificates in responses.* * * * This extension is identified by the object identifier id-pkix-ocsp-* * non-issued-cert.* * * * id-pkix-ocsp-non-issued-cert OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}* * * * The value of the extension SHALL be NULL. This extension MUST NOT be* * marked critical.* Then the text on page 8 would need to be rearranged. The current text is: * This state MAY also be returned if the* * associated CA has no record of ever having issued a certificate with* * the certificate serial number in the request, using any current or* * previous issuing key (referred to as a "non-issued" certificate in* * this document).* * * * The "unknown" state indicates that the responder doesn't know about* * the certificate being requested.* * * * NOTE: The "revoked" state for known non-issued certificate serial* * numbers is allowed in order to reduce the risk of relying* * parties using CRLs as a fall back mechanism, which would be* * considerably higher if an "unknown" response was returned.* * * * When a responder responds revoked to a status request for a non-* * issued certificate, the responder MUST include the extended revoked* * definition response extension (section 4.4.8) in the response,* * indicating that the OCSP responder supports the extended definition* * of revoked state to also cover non-issued certificates. In addition,* * the SingleResponse related to this non-issued certificate;* * * * - MUST provide the revocation reason certificateHold (6),* * * * - MUST specify the revocationTime January 1, 1970, and;* * * * - MUST NOT include a CRL References extension (section 4.4.2) or any* * CRL Entry Extensions (section 4.4.5).* Proposed text for a replacement: * The "unknown" state indicates that the responder doesn't know about* * the certificate being requested.* * * * If the OCSP responder knows that CA identified in the request has* * no record of ever having issued a certificate with the certificate* * serial number in the request, using any current or previous issuing* * key (referred to as a "non-issued" certificate in this document),* * the OCSP responder SHALL respond either "revoked " or "unknown".* * * * Note: The "revoked" state for known non-issued certificate serial* * numbers is allowed in order to reduce the risk of relying parties* * using CRLs as a fall back mechanism, which would be possible when* * the "unknown" response is returned.* * * * When a responder responds revoked or unknown to a status request* * for a non-issued certificate, the responder MUST include the* * non-issued certificate extension (see section 4.4.8) in the* * response.* * * * When a responder responds revoked to a status request for a non-* * issued certificate, in addition, the responder:* * * * - MUST provide the revocation reason certificateHold (6),* * * * - MUST specify the revocationTime January 1, 1970, and;* * * * - MUST NOT include a CRL References extension (section 4.4.2) or any* * CRL Entry Extensions (section 4.4.5).* Finally, the last bullet on page 4 should be reworded: Current text: * o Section 4.4.8 specifies a new extension that indicates that the* * responder supports the extended use of the "revoked" response* * for non-issued certificates defined in section 2.2.* ** Proposed replacement text: * o Section 4.4.8 specifies a new extension that indicates that* * the OCSP responder knows that CA identified in the request* * has no record of ever having issued a certificate with the* * certificate serial number present in the request, as defined* * in section 2.2.* *Comment 9:*Solved, if the comment above may be solved. *Comment 20*:This comment is preliminary classified by you as "not broken". However, since you asked: "If you don't replace 4.2.2.3, then what really are you missing ?", I will provide you with an answer. This is the wrong way to state the question. Providing an ASN.1 syntax as in 4.2.1 is not enough: the use of every parameter MUST be explained using English words. So if you explain the use of every parameter after the description of the ASN.1 syntax in section 4.2.1. then section 4.2.2.3 is no more needed and thus can be deleted. The answer to your question "what is really missing" is a description of the use of every parameter listed in the ASN.1 in section 4.2.1 *Comment 21.* While I can agree in general with the intent of the text, I do not understand the first sentence of the Note which speaks of "CA key rollover" and is copied below: * Note: CA key rollover is not prohibited when issuing a certificate* * for an authorized responder for backwards compatibility with* * RFC 2560 [RFC2560]. That is, it is not prohibited to issue a* * certificate for an authorized responder using a different* * issuing key than the key used to issued the certificate being* * checked for revocation. However, such practice is strongly* * discouraged since clients are not required to recognize a* * responder with such certificate as an authorized responder.* I would propose to delete it, since it does not add anything and thus to have: * Note: For backwards compatibility with RFC 2560 [RFC2560], it is* * not prohibited to issue a certificate for an authorized* * responder using a different issuing key than the key used to* * issued the certificate being checked for revocation.* * However, such practice is strongly discouraged since clients* * are not required to recognize a responder with such* * certificate as an authorized responder.* *Comment 24*: The ASN.1 module in annex B.1 is still wrong, since it does not define NoCheck. *Comment 26*: You asked for explanations. Let me provide you with an example when CRLs are being used by the OCSP responder in the background. The OCSP responder needs to make sure that the CRL it uses is valid. If it is simply using published CRLs (i.e. no trusted link with the CA), it needs to make sure that the CA which has issued the CRL has no been revoked. In France, there is a root CA for the Administration. However, the use of that root CA is optional. Thus a Ministry may have its own root, but may also have its key certified by the root CA of the Administration. The OCSP responder may use the root CA of the Ministry, while a relying party may use the root CA of the Administration (or the reverse) to validate the CRL for the target certificate. Thus the revocation status will be different if the certificate of the CA of the Ministry is revoked by the root CA of the Administration. *CATEGORY 3* *Comments*2, 3, 7, 10, 12, 14, 15, 16, 17, 25 and 27. *CATEGORY 4* Page 4. The indentation of the bullets in section 1 is not uniform. Bullets 1, 4, 5 and 9 have problems. Page 4. The fact that there is now an Annex B.2 dealing with the 2008 ASN.1 syntax is missing. This should be added. Page 10. Change "*Se further section 4.2.2.2"*into "*See further section 4.2.2.2" * Denis ** ===================================================================================== > Denis, > > Responding to your comments below. > > However, one general remark to make recurring comments easier to > understand. > > The WG decided to adopt a minimalistic approach to updating RFC 2560. > That means that > > 1. We don't change anything from RFC 2560 unless it is broken, or the > industry clearly need clarifications in order to avoid > interoperability issues. > 2. We retain the document structure of RFC 2560 as much as possible > to allow easy comparison of what the changes are in comparison > with RFC 2560. > > > One can always think up more clever ways to write things out in words. > But that also comes with a risk. > The current words has been around for a long time and we know from > experience which words worked to produce working implementations, and > which did not. > Introducing new ways to say the same thing may introduce new problems > and people might disagree on what the new perfect wording should be. > And this could go on forever. > > So when my reply is "Not broken", then that is because the current > wording does not have such problems that is merits a change. > > > > From: Denis Pinkas > > Date: Sunday, January 20, 2013 5:12 PM > To: Stefan Santesson >, > Stephen Kent > > Cc: pkix > > Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC > > Please find 32 comments on draft-ietf-pkix-rfc2560bis > > 1.The document states: > > ** responded to separately> > > > Responded to separately. > > 2.The current text from section 2 states: > > 2. Protocol Overview > > > > In lieu of or as a supplement to checking against a periodic CRL, it > > may be necessary to obtain*timely information* regarding the > > revocation status of a certificate (cf. RFC5280], Section 3.3). > > Examples include high-value funds transfer or large stock trades. > > > > The Online Certificate Status Protocol (OCSP) enables applications to > > determine the (revocation) state of an identified certificate. OCSP > > may be used to satisfy some of the operational requirements of > > providing*more timely revocation information* than is possible with > > CRLs and may also be used to obtain additional status information. > > > > This text is misleading because readers may think that OCPS necessarily provides "timely information". > > > > > "may" does not mean "necessarily". > > Proposed text replacement: > > > > *The Online Certificate Status Protocol (OCSP) is a client-server * > > *protocol which enables applications to obtain the revocation status * > > *of one or more certificates either "good", "revoked", or "unknown".* > > ** > > *The revocation status may be provided by the server either using a * > > *real time access to a database of issued certificates, or using a * > > *batch access to a database of issued certificates, or using a * > > *real time access to a database of revocation statuses of issued * > > *certificates, or using a batch access to a database of revocation * > > *statuses of issued certificates, or using CRLs, or using a * > > *combination of base CRLs and delta CRLs.* > > ** > > *In the first case, it is possible to obtain timely revocation > status * > > *information, whereas in the other cases, the freshness of the * > > *revocation status is not better than the mechanisms it is based on.* > > > > > > > Not broken > > 3.The current text from section 2 states: > > > > An OCSP client issues a status request to an OCSP responder and > > Suspends acceptance of*the certificate in question* until the > > responder provides a response. > > > > This protocol specifies the data that needs to be exchanged between > > an application checking the status of a certificate and the server > > providing that status. > > > > Thus is insufficient for an overview. More details are needed to know what the document provides, > in particular that the request may contain several requests for several certificates issued by different CAs. > The possibility of using extensions should also be advertised. > > > > Proposed text replacement: > > > > When using OCSP, an OCSP client issues a certificate revocation > > status request to an OCSP responder *for one or more certificates * > > *issued by the same CA or for one or more certificates issued by * > > *different CAs *and then suspends acceptance of the certificate(s) > > in question until the responder provides a response. > > This document specifies the data that needs to be exchanged between > > an application checking the status of a certificate and the server > > providing that status. > > *OCSP may also provide additional status information using * > > *extensions. * > > > Not broken > > 4.Page 6. Editorial. Punctuation and a CR/LF are missing. > > The text states: > > * 3. the request contains the information needed by the responder If* > > * any one of the prior conditions are not met, the OCSP responder* > > * produces an error message; otherwise, it returns a definitive* > > * response.* > > It should state: > > * 4. the request contains the information needed by the responder.* > > * * > > * If any one of the prior conditions are not met, the OCSP responder* > > * produces an error message; otherwise, it returns a definitive* > > * response.* > > > Fixed in draft 10. > > 5.On page 7, the text states: > > ** > > *All definitive response messages SHALL be digitally signed. The key* > > *used to sign the response MUST belong to one of the following:* > > * * > > * - the CA who issued the certificate in question* > > * - a Trusted Responder whose public key is trusted by the requester* > > * - a CA Designated Responder (Authorized Responder) who holds a* > > * specially marked certificate issued directly by the CA, indicating* > > * that the responder may issue OCSP responses for that CA.* > > ** > > The paragraph is ambiguous on several aspects. > > Delegation is addressed in at least three different places, but > with different terms and conditions. > If some one picks a sentence in one paragraph rather than another, > it will lead to a different conclusion. > RFCs are supposed to be clear. > > On page 10, the current text states in section*2.6 OCSP Signature > Authority Delegation *states: > > > > *The key that signs a certificate's status information need not be > the* > > *same key that signed the certificate.**A certificate's issuer* > > *explicitly delegates OCSP signing authority by issuing a certificate* > > *containing a unique value for extendedKeyUsage in the OCSP signer's* > > *certificate. This certificate MUST be issued directly to the* > > *responder by the cognizant CA.* > > > > On page 16, there is a section *4.2.2.2***called*"**Authorized > Responders"*dealing with the same topic. > > Section 4.2.2.2 states: > > *The key that signs a certificate's status information need not be > the* > > *same key that signed the certificate**. It is necessary however to* > > *ensure that the entity signing this information is authorized to do* > > *so.Therefore, a certificate's issuer MAY either sign the OCSP* > > *responses itself or it MAY explicitly designate this authority to* > > *another entity.OCSP signing delegation SHALL be designated by the* > > *inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate* > > *extension included in the OCSP response signer's certificate.This* > > *certificate MUST be issued directly by the CA that issued the* > > *certificate in question.* > > ** > > *The CA SHOULD use the same issuing key to issue a delegation* > > *certificate as was used to sign the certificate being checked for* > > *revocation. Systems relying on OCSP responses MUST recognize a* > > *delegation certificate as being issued by the CA that issued the* > > *certificate in question only if the delegation certificate and the* > > *certificate being checked for revocation was signed by the same > key.*** > > The last sentence above in yellow is the key sentence that is > missing in the two other sections. > > > > Most implementations only support the case where the OCSP Responder receives an OCSP certificate that is signed by the same key > that was used to sign the target certificate. They do not support the case where the OCSP Responder receives an OCSP certificate > that is signed by a key that is different from the one that was used to sign the target certificate. > > It is inappropriate to have three sections dealing with the same > topic with a slightly different meaning. > > It is proposed the following. > > On page 7, after: > > * - a CA Designated Responder (Authorized Responder) who holds a* > > * specially marked certificate issued directly by the CA, indicating* > > * that the responder may issue OCSP responses for that CA.* > > it is proposed to add "(*see section 4.2.2.2 for further > details**)"*, so that the reader knows that more details are > provided later on. > > Then we do not need two sections to address delegation which start > with the same sentence: > > > "*The key that signs a certificate's status information need not > be the same key that signed the certificate".* > > ** > > It is thus proposed to delete section 2.6. > > Section 4.2.2.2 will thus remain the single section providing full > details. > > > > > I have added references to section 4.2.2.2 in the quoted sections in > 2.2 and 2.6. > (will be included in draft 11) > > > 6. Page 7, the text states: > > * A definitive response message is composed of:* > > * * > > * - version of the response syntax* > > * - name of the responder* > > * - responses for each of the certificates in a request* > > * - optional extensions* > > * - signature algorithm OID* > > * - signature computed across hash of the response* > > This description does not fit with the ASN.1 syntax which is > detailed later on, and in particular: > > * ResponseData ::= SEQUENCE {* > > * version [0] EXPLICIT Version DEFAULT v1,* > > * **responderID ResponderID,* > > * producedAt GeneralizedTime,* > > * responses SEQUENCE OF SingleResponse,* > > * responseExtensions [1] EXPLICIT Extensions OPTIONAL }* > > Proposed text replacement: > > *A definitive response message is composed of:* > > ** > > *- a response status and if there is no error, the following:* > > *- the version of the response syntax,* > > *- an identifier of the OCSP server,* > > *- the time at which the response was produced,* > > *- single responses for each of the target certificates,* > > *- optional extensions,* > > *- the signature algorithm OID,* > > *- the signature computed across hash of the response, and* > > *- optional certificates.* > > > This is an overview section. We ought not try to duplicate the level > of detail provided in the detailed protocol section. > A "definitive response" according to tho 2.1 is a response to an > error-free request, so your first remark is redundant. > > I have added a note about time to the current list, and changed "name" > to identifier in bullet 2. > (will be included in draft 11) > > 7.The text states on page 7: > > *The response for each of the certificates in a request consists of* > > ** > > *-target certificate identifier* > > *-certificate status value* > > *-response validity interval* > > *-optional extensions* > > However, there are no explanations for the purpose of these > parameters and how they should be processed. > > There are also no explanations on how to process a single response > and how to verify that it is its presence within the signed structure > is valid or not valid. This is a major deficiency of the current > description of RC 2560 where there is no explanation on how to > validate > a single response. > > Text proposal to be added after: > > *The purpose of the identifier of the OCSP server is to allow OCSP * > > *clients to find whether the definitive response was signed by a CA * > > *or by an OCSP Responder.* > > ** > > *The identifier of the OCSP server SHOULD either be the name or the * > > *key from a CA, or the name or the key from a OCSP Responder.* > > ** > > *Unless there exist local rules (which are outside the scope of this * > > *document) for verifying that a single response is correctly signed, * > > *the following applies:* > > *When the identifier matches with the name of the CA which has > issued * > > *the target certificate or corresponds to the key used to issue the * > > *target certificate, then a single response is correctly signed * > > *only if the digital signature of the OCSP response is valid using > the * > > *key used to sign the target certificate.* > > ** > > *When the identifier does not match with the name of the CA which > has * > > *issued the target certificate or does not correspond to the key > used * > > *to issue the target certificate, then an single response is > correctly * > > *signed only if :* > > ** > > *(a) there exists in the response an OCSP certificate issued by * > > *the CA which has issued the target certificate which is * > > *signed by the same key as the one used to issue the * > > *target certificate, and* > > ** > > *(b) the digital signature of the OCSP response is valid using * > > *the subjectPublicKey contained in this OCSP certificate.* > > > Not broken. > All of this is already covered by the document. > > 8.The text states on page 7: > > The "revoked" state indicates that the certificate has been revoked > > *(either permanently or temporarily (on hold)). *This state MAY > also be > > returned if the responder knows that the requested certificate has > > *never been issued during the history of the associated CA *using any > > current or previous issuing key. ** > > The text is ambiguous because there are two embedded parenthesis > and it is unclear whether the inner parenthesis means "i.e" or "e.g". > This single sentence may let think that on hold is the single case > for temporarily revocation. Since neither X.509 nor RFC 5280 address > the case of a temporary revocation in the context of an OCSP > response (but only in the context of CRLs), we are able to add > another case > of temporary revocation which will only apply in the context of OCSP. > > The above sentence using the terms"*never been issued during the > history of the associated CA*"does not capture the fact > that it could be issued in the future, hence why using"*not yet > been used"*would be more appropriate. > > Finally, it would have been more logical to use "unknown". So it > is important to add a note to explain why we have chosen that case > for "legacy clients", > otherwise the people who have not participate to the exchanges > will not understand. > > Proposed text replacement: > > *The "revoked" state indicates that the certificate has been revoked,* > > * either permanently or temporarily.* > > > > A certificate may be temporarily revoked either because it is > > placed on hold (*i.e. the revocation reason is certificateHold*) or > > because the responder is able to know, using a positive list of > > issued certificates, that the serial number from the requested > > certificate has*not yet been used* by the CA to issue a certificate > > (*i.e. the revocation reason is notIssuedOrIrregularlyIssued*). > > > > *NOTE: The "revoked" state is used rather than the "unknown" state, to* > > * make sure that relying parties that were conformant to RFC 2560* > > * will not use CRLs as a fall back mechanism.* > > > > > I removed the double parenthesis and adopted your clarification with > regard to "on hold". > > The text in draft 10 has changed from what you have commented on. I > believe that text is better. > > You "Note" has problems. > > 1. We do not prevent responders to respond "unknown" if their > assessment is that this is an appropriate response, considering > what they know about the requested serial number. Thus the term > "is used" is misleading. > 2. This mechanisms does not "make sure" that the clients do anything. > It's up to the discretion of the relying party to decide what > source of revocation checking they rely on. This does however > reduce the risk of clients falling back to CRL:s > 3. This mechanism is not just relevant to old clients, but also to > new one for the same reason. > > > I have adopted a modified version of your Note: > > NOTE: The "revoked" state for known non-issued certificate serial > numbers is allowed in order to reduce the risk of relying > parties using CRLs as a fall back mechanism, which would be > considerably higher if an "unknown" response was returned. > > > > 9.The text states on page 8: > > *When a responder responds revoked to a status request for a non-* > > *issued certificate, the responder MUST also;* > > ** > > *- include the extended revoked definition response extension* > > *(section 4.8), indicating that the OCSP responder supports the* > > *extended definition of revoked state to also cover non-issued* > > *certificates,* > > ** > > *- provide the revocation reason certificateHold (6), and;* > > ** > > *- specify the revocation date January 1, 1970. * > > As already explained on the PKIX list, using the revocation > reason**certificateHold is not appropriate > because it changes the meaning of certificateHold. > > The extended revoked definition response extension is a means to > signal that it not a true certificate hold but a "not issued > certificate". > Legacy applications cannot take advantage of it. > > Some applications which handle non repudiation enter a waiting > state when the revocation reason certificateHold is used thus > it is not appropriate to overload the meaning. > > ** > > It is possible to use another enumeration for signalling that > specific case: > > notIssuedOrIrregularlyIssued (7). > > ** > > Thus for new applications it would be much better to use > notIssuedOrIrregularlyIssued (7) as already proposed on the PKIX list. > > The above sentence uses the text: > > > > "a status request for a*non-issued certificate*" > > > > whereas it would be more appropriate to state: > > > > "a status request for a* serial number which has not been used by the CA or used irregularly to issue a certificate".* > > * * > > Placing the ASN.1 description at such a place in the document is inappropriate since the ASN.1 structures have not yet been described. > Thus only the functional aspects should be mentioned, but not the ASN.1 implications. > > * * > > BTW, the description should follow the same order as the ASN.1. This is not the case. > > > > This text should be deleted from this section and the appropriate text should be added when the parameters of the response are described. > > > > The text proposed in the previous comment should be sufficient at this time of reading. > > > > In addition, section*4.4.8Extended Revoked Definition *should be > deleted.** > > > > > > > The referred text has been updates in draft 09. > > This has been discussed on the list and you have yet to convince the > list of your new reason code. > I disagree as the risk of running into problems with the deployed base > of application is hugely larger with introduction of a new reason > code, rather than using certificateHold. > No application should be broken, since no application have business > asking for non-issued cert serial numbers in the first place. > Secondly, no application can assume that a certificateHold reason will > be cleared any time soon. > > > 10.The text states on page 8: > > *2.4Semantics of thisUpdate, nextUpdate and producedAt* > > This section is misplaced. At this time of reading, the reader > does not know that thisUpdate, nextUpdate and producedAt are values > used by the ASN.1 structures. It is appropriate to describe what > theses parameters mean when the ASN.1 syntax is described. > The current ASN.1 syntax is very badly described. One would expect > that after every ASN.1 structure description every parameter is > described. > Unfortunately this is not the case. > > The text from this section is not aligned with the text that is > present in section 4.2.2.1. > > In particular, in section 2.4: > > ** > > *If nextUpdate is not set, the responder is indicating that newer* > > *revocation information is available all the time.* > > While in section 4.2.2.1: > > *Responses where the nextUpdate value is not set are equivalent * > > *to a CRL with no time for nextUpdate (see Section 2.4).* > > It is not appropriate to have two different descriptions in two > different places. > > Delete section 2.4. See comment number 19 for the description of > these parameters. > > > Not broken. > The current text segments fits well into a protocol overview section. > > 11.Section 2.5 is also misplaced. They use values from the ASN.1 > syntax which has not yet been described. > They should be moved or incorporated in the document once the > ASN.1 description has been done. > > > Not broken. > > 12.Remainder: Section 2.6 should be deleted (see comment number 5). > > > Not broken. > > 13.Section 2.7 states: > > *2.7CA Key Compromise* > > ** > > *If an OCSP responder knows that a particular CA's private key has* > > *been compromised, it MAY return the revoked state for all* > > *certificates issued by that CA.* > > This section is misleading and should be removed. The reason is > the following: > > The relying party must verify that the singleResponse is signed by > a responder which is entitled to do so. > > a) If the CA key has been compromised and if the response is > signed by that CA key then the singleResponse will be discarded > when performing the certification path validation _whatever the > content of the response may be_. > > b) If the CA key which has issued the OCSP certificate has been > compromised and if the response is signed by the key present > in the OCSP certificate then the singleResponse will be discarded > when performing the certification path validation > _whatever the content of the response may be_. > > Security must be provided using the validation of the > certification path. Thus it does not matter what the OCSP > responder states. > > > > Not broken. > An OCSP responder does not have to be chained to the broken CA. The > relying party may have other trust configuration at choice. > > > > 14.The text states on page 11: > > *3.2Signed Response Acceptance Requirements* > > ** > > *Prior to accepting a signed response as valid, OCSP clients SHALL* > > *confirm that:* > > ** > > *1. The certificate identified in a received response corresponds to* > > *that which was identified in the corresponding request;* > > ** > > *2. The signature on the response is valid;* > > ** > > *3. The identity of the signer matches the intended recipient of the* > > *request.* > > ** > > *4. The signer is currently authorized to sign the response.* > > ** > > *5. The time at which the status being indicated is known to be* > > *correct (thisUpdate) is sufficiently recent.* > > ** > > *6. When available, the time at or before which newer information > will* > > *be available about the status of the certificate (nextUpdate) is* > > *greater than the current time.* > > This section is misplaced since it uses terms from the ASN.1 > syntax and the protocol description has not yet been made, > since it is the next section 4. Its text is not correct either. > > This description does not take into account the fact that > a*BasicOCSPResponse *may contain one or several *SingleResponses. * > In particular, the sentence"*The signer is currently authorized to > sign the response*" is misleading because a signer > may be authorized to include some***SingleResponses *but not > necessarily all of them. > > The appropriate explanations should be done after the description > of the response, when describing the processing of the response. > > Delete that section. > > > Not broken. > > 15.On page 12, after the ASN.1 description, the only parameters > which are described are: > > *hashAlgorithm,**issuerNameHash, issuerKeyHash and serialNumber.* > > ** > > This is insufficient.In order to cover the full list of > parameters, the following text is proposed: > > *requestorName is optional and MAY be used by the server for access * > > *control and audit purposes.* > > ** > > *requestList contains one or more single requests.* > > ** > > *requestExtensions is OPTIONAL.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.* > > ** > > *reqCert contains the identifier of a target certificate.* > > ** > > *issuerNameHash is the hash of the Issuer's distinguished name.The * > > *hash shall be calculated over the DER encoding of the issuer's name * > > *field in the certificate being checked. * > > ** > > *issuerKeyHash is the hash of the Issuer's public key.The hash * > > *shall be calculated over the value (excluding tag and length) of > the * > > *subject public key field in the issuer's certificate.The hash * > > *algorithm used for both these hashes, is identified in * > > *hashAlgorithm. * > > ** > > *The primary reason to use the hash of the CA's public key in * > > *addition to the hash of the CA's name, to identify the issuer, * > > *is that it is possible that two CAs may choose to use the same * > > *name (uniqueness in the Name is a recommendation that cannot be * > > *enforced). Two CAs will never, however, have the same public key * > > *unless the CAs either explicitly decided to share their private * > > *key, or the key of one of the CAs was compromised.* > > ** > > *serialNumber is the serial number of the certificate for which * > > *status is being requested.* > > ** > > *singleRequestExtensions is OPTIONAL.Any specific extension is * > > *OPTIONAL.The critical flag SHOULD NOT be set for any of them. * > > ** > > *The requestor MAY choose to sign the OCSP request.In that case, the* > > *signature is computed over the tbsRequest structure.If the request* > > *is signed, the requestor SHALL specify its name in the requestorName* > > *field.Also, for signed requests, the requestor MAY include* > > *certificates that help the OCSP responder verify the requestor's* > > *signature in the certs field of Signature.* > > > Not broken. > The current text is short, but it is actually sufficient from the > context of the ASN.1 definitions of the section. This is a detailed > protocol section and the reader need to understand ASN.1 in any case > to understand and implement the section. > The information about criticality is already covered in the extension > section. > > > 16.Section 4.1.2 is called:"*Notes on the Request Syntax"* > > The first paragraph has been moved after the description > of*issuerKeyHash *and thus is no more needed. > > The second paragraph has been moved after the description > of*requestExtensions. * > However, the sentence > " *Unrecognized extensions MUST be ignored (unless they have the > critical flag set and are not understood)*" > has been deleted since it applies to the OCSP responder and not to > the OCSP client. Thus it is no more needed. > > The third paragraph applies to signed requests. However, it should > belong to a section dedicated on how clients should build OCPS > requests, > which is currently missing. See the next comment. > > This section should be deleted. > > > Not broken. > > 17.There should be a new section called: "*Requirements for OCSP > clients". * > > It is important first to re-advertise that the request may be > about several certificates. > Thus it is important to describe the process for building a > request, which is currently missing. > > *An OCSP request allows getting in the same response the revocation * > > *status of one or more certificates.In order to request the * > > *status of one or more certificates in a single request, OCSP * > > *clients SHALL follow the following rules :* > > ** > > *For each candidate certificate, OCSP clients SHALL verify * > > *whether there exists a locally defined rule for the certificate in * > > *question which indicates the URI where the OCSP responder is * > > *located.If this rule exists, it SHALL be followed. * > > ** > > *Otherwise, OCSP clients SHALL determine whether the candidate * > > *certificate contains an AIA extension with an accessMethod which * > > *contains the id-ad-ocsp OID.If it is the case, the accessLocation * > > *contains a uniformResourceIdentifier (URI) which indicates the * > > *location of the OCSP server for that certificate. * > > ** > > *Certificates that contain the same URI MAY be grouped in a single * > > *request.* > > ** > > *Note:For each candidate certificate, when performing the path * > > *validation algorithm, the OCSP client SHOULD verify that the * > > *current time is within the validity period of the target * > > *certificate.Certificates which are outside their validity * > > *period SHOULD NOT be included in the request.* > > *The requestor MAY choose to sign the OCSP request. In that case, the* > > *signature is computed over the tbsRequest structure. If the request* > > *is signed, the requestor SHALL specify its name in the requestorName* > > *field. Also, for signed requests, the requestor MAY include* > > *certificates that help the OCSP responder verify the requestor's* > > *signature in the certs field of Signature.* > > > Not broken. > > Your text may provide guidance that could be useful to some > implementers, but is completely beyond this document and further, not > generally applicable or true. > As an example, an organisation may setup an in house locally > configured OCSP responder that responds to all certificates "out > there" that is relevant to that organisation. > Such clients would just blindly send OCSP requests to their local > responder, disregarding any information in the cert. > It's totally beyond this spec to have an opinion about this. > > > 18.The text states on page 14: > > *The responder MAY include certificates in the* > > *certs field of BasicOCSPResponse that help the OCSP client verify > the* > > *responder's signature. If no certificates are included then certs* > > *SHOULD be absent.* > > While this sentence is true, it is not sufficient. In order to > allow verifying every *SingleResponse*, > it is important to include the relevant certificates which are > pertinent to every *SingleResponse.* > > Proposed full text replacement: > > The responder MAY include certificates in the certs field of > > BasicOCSPResponse that help the OCSP client verify the responder's > > signature. > > *For every SingleResponse where the responder is not a CA, the * > > *responder SHALL include the relevant OCSP certificate in the certs * > > *field of BasicOCSPResponse in order to allow the OCSP client * > > *verifying the responder was entitled to include that SingleResponse * > > *in the signed BasicOCSPResponse.* > > ** > > **If no certificates are included then certs SHOULD be absent. > > > Not broken. > > This requirement would break backwards compatibility with RFC 2560. > Further this would not be needed for a locally configured responder. > > 19.Page 15. The ASN.1 syntax should be changed in order to be able > to use the enumeration case 7 that is not used for CRLs. > This leads to the following change: > > Current text: > > ** > > *revocationReason[0]EXPLICIT CRLReason OPTIONAL }* > > Proposed text change: > > Current text: > > ** > > *revocationReason [0]EXPLICIT RevocationReason OPTIONAL }* > > *RevocationReason ::= ENUMERATED {* > > *unspecified(0),* > > *keyCompromise(1),* > > *cACompromise(2),* > > *affiliationChanged(3),* > > *superseded(4),* > > *cessationOfOperation(5),* > > *certificateHold(6),* > > *notIssuedOrIrregularlyIssued (7),* > > *removeFromCRL(8),* > > *privilegeWithdrawn(9),* > > *aACompromise(10) }* > > > Not broken. > > You have to convince the list about your new reason code. > > 20.Page 15. After the ASN.1 syntax, there is no description of > every parameter, neither on its use > (except a few words in section*4.2.2.1 Time *about*thisUpdate, > nextUpdate and producedAt).* > > ** > > Every parameter needs to be described and explained. > > ** > > *responderID indicates either the name or the key from a CA, or the * > > *name or the key from a OCSP Responder.* > > ** > > *producedAt indicates the time at which this response was signed.* > > ** > > *responses contains one or more single responses.* > > ** > > *responseExtensions is OPTIONAL.Any specific extension is OPTIONAL.* > > *The critical flag may or may not be set.* > > ** > > *certID is usually a copy of the same field which was placed in the * > > *request, but for OCSP responders which pre-produce signed responses * > > *certID may be the identifier of a target certificate that was not * > > *present in the request (see the end of section 4.2).* > > ** > > *certStatus indicates the status of the certificate: either good, * > > *revoked or unknown.* > > ** > > *thisUpdate indicates the time at which the status being indicated * > > *is known to be correct.* > > ** > > *nextUpdate indicates the time at or before which newer information * > > *will be available about the status of the certificate.If * > > *nextUpdate is not set, the server is indicating that newer * > > *revocation information is available all the time. * > > ** > > *If nextUpdate is set, it often corresponds to the {thisUpdate, * > > *nextUpdate} interval in CRLs.Responses whose nextUpdate value is * > > *earlier than the local UTC time value SHOULD be considered * > > *unreliable.Responses whose thisUpdate time is later than the local * > > *UTC time SHOULD be considered unreliable.* > > ** > > *singleExtensions is OPTIONAL.Any specific extension is OPTIONAL.* > > *The critical flag SHOULD NOT be set for any of them.* > > ** > > *revocationTime indicates the time at which the certificate was * > > *revoked.* > > ** > > *revocationReason is OPTIONAL. It includes all the cases that are * > > *present in CRLReason used for CRLs and an additional case 7 which is* > > *not used for CRLs.Case 7 is called notIssuedOrIrregularlyIssued. * > > ** > > *- "notIssued" corresponds to the case where the certificate * > > *serial number that was sent was erroneous and has not yet * > > *been used by the CA at the time of the query,* > > ** > > *- "irregularlyIssued" corresponds to the case where the * > > *certificate serial number that was sent really exists in a * > > *certificate that is correctly signed, but to its knowledge * > > *the CA has not issued a certificate with such a serial * > > *number. As an example, it may have been issued by the CA * > > *because the RA was compromised. * > > ** > > * When a responder responds revoked to a status request for which it* > > * knows that the serial number has not been used by the CA or has* > > * been irregularly used irregularly to issue a certificate, then* > > * in RevokedInfo the responder MUST:* > > * * > > * - specify the revocationTime : January 1, 1970,* > > * - provide the revocationReason: notIssuedOrIrregularlyIssued (7).* > > * * > > * and in SingleResponse the responder MUST NOT include the nextUpdate.* > > ** > > *The response MUST include a SingleResponse for each certificate in* > > *the request and SHOULD NOT include any additional SingleResponse* > > *elements.However, there is one exception: * > > ** > > *OCSP responders MAY pre-produce signed responses specifying the * > > *status of certificates at a specified time.The time at which * > > *the status was known to be correct SHALL be reflected in the * > > *thisUpdate field of the response. * > > ** > > *OCSP responders that pre-generate status responses MAY return * > > *responses that include additional SingleResponse elements if* > > *necessary to improve response pre-generation performance or cache* > > *efficiency (as permitted in [RFC5019]).* > > Since the text above provides all the explanations at the level of > the ASN.1 parameters, the general text > from section*4.2.2.3 Basic Response *is no more need and should be > deleted.** > > ** > > > Preliminary I would say "not broken". > If you don't replace 4.2.2.3, then what really are you missing? > > 21.0n page 16, there is a section *4.2.2.2***called*"**Authorized > Responders"*** > > Section 4.2.2.2 states: > > *(...)* > > *This certificate MUST be issued directly by the CA that issued the* > > *certificate in question.* > > ** > > *The CA SHOULD use the same issuing key to issue a delegation* > > *certificate as was used to sign the certificate being checked for* > > *revocation. Systems relying on OCSP responses MUST recognize a* > > *delegation certificate as being issued by the CA that issued the* > > *certificate in question only if the delegation certificate and the* > > *certificate being checked for revocation was signed by the same key.* > > This section would need to reformatted to address CA requirements > first and then OCSP responder requirements: > > *(...)* > > *This certificate MUST be issued directly by the CA that issued the* > > *certificate in question.The CA SHOULD use the same issuing key to * > > *issue a delegation certificate as was used to sign the certificate * > > *being checked for revocation. * > > ** > > *Systems relying on OCSP responses MUST _be able to_ recognize a * > > *delegation certificate as being issued by the CA that issued the * > > *certificate in question if the delegation certificate and * > > *the certificate being checked _were_ signed by the same key.* > > > I disagree. The CA is actually free to do anything, but cannot expect > the client to recognise the responder as authorised unless the same > private key is used. > The current text places the requirement where they belong. > > 22.On page 17, the text states: > > *They MUST reject the* > > *response if the certificate required to validate the signature on > the* > > *response fails to meet at least one of the following criteria:* > > This is ambiguous. It is inappropriate to have a negative > statement like"*They MUST reject". * > The sentence should be turned in the positive form"*They SHALL > accept"* > > Since the ASN.1 syntax has now be described, it is possible to be > more specific. > > The first occurrence of the word "response" should be changed into > "singleResponse", while the second occurrence > of the word "response" should be changed into "ResponseData" > > Proposed text replacement: > > *They SHALL accept a singleResponse if the certificate required to * > > *validate the signature placed on the ResponseData meets one of the * > > *following criteria:* > > > > No, this change is not backwards compatible. > So state the requirements for rejection is not equivalent to stating > requirements for acceptance. > There may be other locally configured reasons to reject in addition to > those listed in the standard. > > > 23.On page 17, the text states: > > *3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage* > > *extension and is issued by the CA that issued the certificate in* > > *question as stated above."* > > In order to be crystal clear, it is proposed to change the wording > in the following way: > > *3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage* > > *extension and was signed by the CA using the same key that used * > > *to issue the certificate in question.* > > > No, issuing with another key is not prohibited, and may be accepted by > some clients as an authorised responder. > > 24.On page 17, the text states: > > *This SHOULD be a non-critical extension. The value of the extension * > > *SHALL be NULL.* > > ** > > The ASN.1 syntax is missing. Add: > > ** > > *NoCheck ::= NULL* > > ** > > > Moving this to a separate discussion. > I'm not sure what the preferred way to describe this is. > > > 25.Remainder: On page 18, the general text from section***4.2.2.3 > Basic Response***is no more needed and > should be deleted. See comment 20. > > ** > > > Not broken. > > 26.On page 24, text should be added to the Security consideration > section: > > *Different results when using OCSP and CRLs* > > ** > > *OCSP clients or verifiers must build and verify a certification > path * > > *for each target certificate up to a trusted root.When an OCSP * > > *Responder is using published CRLs, it must also build and verify a * > > *certification path for the CRLs it uses up to a trusted root.* > > ** > > *However, it should be realized that the root used by an OCSP * > > *Responder to verified these CRLs is not necessarily the same as the * > > *one that would be used by the OCSP client, if it were going to > verify * > > *the CRLs itself.Hence the revocation status may not be identical * > > *in both cases.* > > ** > > ** > > > I don't understand this one. > > 27.On page 24, text should be added to the Security consideration > section: > > ** > > *Denial of service attack using a flood of queries* > > ** > > *A denial of service vulnerability is evident with respect to a > flood * > > *of queries.The production of a cryptographic signature * > > *significantly affects response generation cycle time, thereby * > > *exacerbating the situation. * > > ** > > *The flood of queries may either come from a flood attack or from > the * > > *fact that there are too many certificates supported by the same > OCSP * > > *responder.In the later case, the number of queries can be * > > *reduced by using a technique similar to the splitting of CRLs: * > > ** > > *When a block of certificates have been issued with the same * > > *accessLocation in the AIA extension field of these certificates, * > > *then the accessLocation should be changed.In this way, a given * > > *OCSP server will only be responsible for a block of certificates.* > > ** > > > If the security considerations section is talking about splitting OCSP > responders in this way, then the document itself need to introduce the > subject. > I would suggest that it is beyond this update to do so. > > ** > > 28.On page 31, the text states. > > *An alternative to this module that conforms to the 2002 version of * > > *ASN.1 may be found in Section 4 of [RFC5912]. * > > ** > > RFC 5912 omits to define the nocheck extension. Thus it is > inappropriate to refer to RFC 5912. > > The corrected module should be defined in this new draft. > A corrected module is providedin *draft-pinkas-rfc2560bis-03.* > > > Will move this (as stated above) to a separate discussion. > > 29.Different topics are not covered by the document. These topics > are important. > The following comments propose text to be placed in annexes. Three > annexes are being proposed. > > Note: The texts are extracted from*draft-pinkas-rfc2560bis-03.* > > > Not broken. > Each such amendment need to be thoroughly reviewed and motivated. > > > 30.First annex being proposed. This annex is important, because > key rollover is not addressed in the draft. > > *KEY ROLLOVER* > > ** > > *1. CA that directly supports an OCSP service* > > ** > > *When a CA that directly supports an OCSP service performs a key * > > *rollover:* > > ** > > *- for certificates issued under the old key, the CA SHALL continue * > > *to sign the revocation status of OCSP responses with that old key * > > *at least until all these certificates are expired, and* > > ** > > *- for certificates issued under the new key, the CA SHALL change > the * > > *accessLocation in the AIA extension field of these certificates * > > *and sign the revocation status of OCSP responses with that new key * > > *at least until all these certificates are expired.* > > ** > > *Note: The change in accessLocation is necessary when the CA rekeys * > > *to meet the following constraints imposed by this standard: * > > ** > > *1) a BasicOCSPResponse can only be signed using a single * > > *private key; * > > ** > > *2) the response must be signed using the same CA key that * > > *was used to sign the certificate in question; and* > > ** > > *3) the OCSP response needs to cover all the certificates * > > *queried in the OCSP request.* > > *2. CA that uses OCSP responders* > > *When a CA that uses OCSP Responders performs a key rollover, then * > > *it MUST either designate a new OCSP Responder or keep the current * > > *OCSP Responder(s).* > > ** > > *If the CA designates a new OCSP Responder, then it SHALL change the * > > *accessLocation in the AIA extension field for the newly issued * > > *certificates and issue an OCSP certificate to the new OCSP > Responder * > > *using its new key.* > > ** > > *If the CA keeps the same OCSP Responder(s), then it SHALL continue * > > *to use the same accessLocation(s) in the AIA extension field for > the * > > *newly issued certificates and issue an OCSP certificate to the * > > *appropriate OCSP Responder(s) using its new key.* > > ** > > *Note: The CA may need to continue issuing certificates to the OCSP * > > *Responder(s) using the old CA key until all the certificates issued * > > *under the CA' old key for which the OCSP Responder(s) are * > > *authoritative have expired.* > > ** > > *3. OCSP Responder key rollover* > > ** > > *When an OCSP Responder performs a key rollover (asynchronously from * > > *a CA key rollover), then each CA which has designated an OCSP * > > *Responder SHALL issue a new certificate for that OCSP Responder and * > > *for each of its issuing keys which meets the following property: * > > ** > > *- the issuing key has been used to sign at least one certificate * > > *which contains an AIA extension designating that OCSP Responder * > > *and that certificate is not yet expired.* > > ** > > *An OCSP Responder key rollover does not affect the values of the * > > *URIs that are placed in the accessLocation field from the target * > > *certificates.One or more OCSP Responder MAY respond to an OCSP * > > *request addressed at a given URI picked from the accessLocation * > > *field from a target certificate.Each OCSP Responder MAY use a * > > *different signing key, as long as it got an OCSP certificate * > > *appropriate for that signing key and for the target certificate. * > > 31.Second annex being proposed. This annex is important because it > describes the validation of an OCSP response in the past > which is of a particular importance when validating electronic > signatures. > > *Response processing by an OCSP client* > > ** > > *OCSP responses can be verified at the current time by an OCSP > client * > > *when receiving a response, whereas old responses can be verified at * > > *a time in the past by a verifier.The algorithm below addresses * > > *both cases.* > > ** > > *Prior to processing a basic response, OCSP clients MUST determine * > > *the checking time, which may be either the current time or a time * > > *in the past.* > > ** > > *OCSP clients or verifiers SHALL check if the response contains * > > *responseExtensions. If such an extension is found and is > recognized, * > > *it MUST be processed.If such a critical extension is found and * > > *is not recognized, the whole OCSP response MUST be considered as * > > *invalid.* > > ** > > *If the checking time is the current time, and if a nonce extension * > > *has been used in the request and is recognized (see section 4.5.1), * > > *OCSP clients MUST check whether the same nonce is present in the * > > *response.If the nonce is not present or is different, then the * > > *OCSP response MUST be discarded.* > > ** > > *Only the single response(s) which are/is of interest SHALL be * > > *checked.* > > ** > > *STEP 1* > > ** > > *OCSP clients or verifiers SHALL verify that the certificate * > > *identified in a single response is of interest.Otherwise, proceed * > > *to step 3.* > > ** > > *If the certificate status included in a single certificate response * > > *is "unknown", then the revocation status of that certificate is * > > *"unknown", and proceed to step 3.* > > ** > > *If the certificate status from the single certificate response is * > > *either "good" or "revoked", OCSP clients or verifiers SHALL check * > > *that the checking time is within the validity period of the target * > > *certificate.If it is not the case, then the revocation status of * > > *that certificate is "unknown" and proceed to step 3.* > > ** > > *If the checking time is the current time, and if a nonce has been * > > *used in the request, then proceed to step 2.* > > ** > > *If the checking time is the current time, and if no nonce has been * > > *used in the request, OCSP clients MUST check that the producedAt* > > *field is within a time window that is "close enough" to the current * > > *time. * > > ** > > *Note: the notion of "close enough" is a local matter.It can be set * > > *to a few minutes to allow for small UTC time differences * > > *between the client and the server or to a few hours in case * > > *the server is producing pre-computed responses.* > > ** > > *If the checking time is a time in the past, verifiers MUST check * > > *that the producedAt field is in accordance with the verification * > > *rules (e.g. close and/or after the date of a time-stamp token).* > > ** > > *In addition, if the nextUpdate field is present, OCSP clients MUST * > > *check that the time which is indicated is greater than the checking * > > *time, otherwise the single response MUST be discarded.* > > ** > > *If checks are successful, then OCSP clients MUST process the * > > *singleExtensions field, if it is present. * > > ** > > *If the criticality flag is set and the extension is not understood, * > > *then the status of the certificate shall be "unknown" and proceed > to * > > *step 3.Otherwise, proceed to step 2. * > > ** > > *If the extension is understood, then the extension MUST be * > > *processed.According to its content proceed either to step 2 or to * > > *step 3. * > > ** > > *STEP 2* > > ** > > *OCSP clients or verifiers MUST build and verify a certification > path * > > *for that certificate up to a trusted root, so that they have the * > > *knowledge of the CA public key value that was used to sign the * > > *target certificate.The revocation status of each certificate of * > > *that certification path (except the target certificate) SHALL be * > > *checked.* > > ** > > *If no path can be built or if one of the certificates of the path > is * > > *revoked, then the revocation status of that certificate is > "unknown", * > > *and proceed to step 3. * > > ** > > *If the certification path (except the target certificate) is valid, * > > *then two cases need to be considered:* > > ** > > *a) If the responderID matches with the name or the key from the CA * > > *which has issued the target certificate, then check whether the * > > *OCSP response is signed by the same key that was used to sign * > > *the target certificate.* > > ** > > *If it is the case, then the revocation status of that * > > *certificate as indicated in the certStatus field is * > > *accepted and proceed to step 3.* > > ** > > *If it is not the case, then the revocation status of that * > > *certificate is "unknown" and proceed to step 3.* > > ** > > *b) If the responderID does not match with the name or the key from * > > *the CA which has issued the target certificate, then it indicates * > > *the name or the key from an OCSP Responder.Check whether there * > > *exists a local rule which applies to this target certificate to * > > *verify that the signature of the BasicOCSPResponse is valid for * > > *that single response.If this rule exists, it SHALL be followed. * > > ** > > *Otherwise check whether there is an OCSP certificate (i.e. which * > > *has both the ocspSigning OID in the extended key usage extension * > > *and the digitalSignature bit in the key usage extension) signed * > > *by the same key that was used to sign the target certificate. * > > *This certificate MUST be present in the certs field from the * > > *BasicOCSPResponse. * > > ** > > *If such certificate is not found or is invalid, then the * > > *revocation status of that certificate is "unknown" and * > > *proceed to step 3.* > > ** > > *If such certificate exists and if the checking time is * > > *within the validity period of this certificate, then it MUST * > > *be verified whether the OCSP response can be verified using * > > *the public key that is present in the OCSP Certificate. * > > ** > > *If it is not the case, then the revocation status of that * > > *certificate is "unknown" and proceed to step 3.* > > ** > > *If it is the case, then it MUST be verified that the OCSP * > > *Certificate has not been revoked.* > > ** > > *If one of these conditions is met, then the status for the target * > > *certificate as indicated in the certStatus field is accepted, * > > *otherwise the revocation status is "unknown".* > > ** > > *STEP 3* > > ** > > *If there exists another single certificate status response for a * > > *target certificate that is of interest, then proceed to step 1. * > > *Otherwise the basic response is now processed.* > > 32.Third annex being proposed. This annex is important because it > provides guidance on how to build an OCSP responder in the three > cases. > Many text portions are similar, but three full texts are provided > in order to provide a better clarity for each of the three cases. > > *1. Request processing by OCSP servers* > > ** > > *The behavior of an OCSP server will be different whether the OCSP * > > *server is a CA acting as an OCSP responder, is an OCSP Responder * > > *which received a delegation from one or more CAs, or is a locally * > > *trusted Responder.* > > ** > > *1.1. Processing by a CA acting as an OCSP responder* > > ** > > *The OCSP responder SHALL maintain a list of entries. Each entry * > > *SHALL contain:* > > ** > > *- the URI associated to the OCSP responder, from which the OCSP * > > *requests are received, * > > ** > > *- the DN from a CA,* > > ** > > *- an issuing public key from a CA,* > > ** > > *- the method(s) used to know for which subset of certificates * > > *issued by the CA it is responsible for, * > > ** > > *- the method(s) used to obtain the revocation status of that * > > *subset of certificates issued under that CA issuing public key, * > > *and* > > ** > > *- the method used to gain access and sign with the private key * > > *corresponding to the issuing public key.* > > ** > > *For a given URI value, the OCSP responder SHALL only use one CA * > > *key pair value. * > > ** > > *When it receives an OCSP request on that URI, the OCSP responder * > > *SHALL handle exceptions according to section 2.3. * > > ** > > *If the OCSP request contains the name of a requestor, the OCSP * > > *responder SHALL verify whether there exists a locally defined rule * > > *which regulates access control.If this rule exists, it SHALL be * > > *followed.* > > ** > > *Then, for each target certificate, the OCSP responder SHALL verify * > > *whether both the hash of the issuer's DN and the hash of the issuer * > > *public key which are present in the request are eligible to a * > > *locally defined rule which indicates that the OCSP responder is * > > *responsible to provide the revocation status of that target * > > *certificate.If this rule exists, it SHALL be followed.* > > ** > > *Otherwise, the OCSP responder SHALL determine whether it is * > > *responsible to provide the revocation status of that target * > > *certificate according to the following rule.* > > ** > > *For each target certificate, the OCSP responder SHALL verify > whether * > > *both the hash of the issuer's DN and the hash of the issuer public * > > *key which are present in the request match respectively with the DN * > > *and the hash of the public key of contained in an entry from the * > > *list of entries maintained by this OCSP responder. * > > ** > > *When there is no match, then the OCSP responder SHALL indicate the * > > *"unknown" status and proceed with the next target certificate from * > > *the OCSP request.* > > ** > > *When there is a match, then the OCSP responder SHALL use the serial * > > *number of the target certificate that is present in the request and * > > *determine the revocation status of that certificate according to * > > *the method(s) defined in the entry. * > > ** > > *When the revocation status is provided by the server using a real * > > *time access to a database of revocation statuses of issued * > > *certificates, then the thisUpdate field SHALL be present in the* > > *SingleResponse response whereas the nextUpdate field SHALL be * > > *missing. * > > ** > > *Otherwise, both the thisUpdate and the nextUpdate fields SHALL be * > > *present in the SingleResponse. * > > ** > > *The time at which this response will be signed MUST be indicated in * > > *the producedAt field from the SingleResponse.* > > ** > > *If a singleRequestExtensions is present in the request it MUST be * > > *processed.* > > ** > > *If there is another target certificate present in the request, it * > > *SHALL be processed in the same way.* > > ** > > *If a requestExtensions is present in the request it MUST be * > > *processed.* > > ** > > *The OCSP response MUST be signed using the CA issuing private key.* > > ** > > ** > > *1.2. Processing by an OCSP Responder* > > ** > > *For each CA from which the OCSP Responder has received a > delegation, * > > *the OCSP Responder SHALL maintain a list of entries. * > > ** > > *Each entry SHALL contain:* > > ** > > *- the URI associated to this OCSP Responder, from which the OCSP * > > *requests are received, * > > ** > > *- the DN from a CA,* > > ** > > *- an issuing public key from a CA,* > > ** > > *- the method(s) used to know for which subset of certificates * > > *issued by the CA it is responsible for, * > > ** > > *- the method(s) used to obtain the revocation status of that * > > *subset of certificates issued under that CA issuing public key,* > > ** > > *- an OCSP certificate, * > > ** > > *- the OCSP public key contained in that OCSP certificate, and* > > ** > > *- the method used to gain access and sign with the OCSP private * > > *key corresponding to that OCSP certificate.* > > ** > > *For a given URI value, the OCSP Responder SHALL only use one OCSP * > > *key pair value.Therefore there cannot be two entries with the * > > *same URI value and a different OCSP public key value.* > > ** > > *NOTE: a BasicOCSPResponse can only be signed using a single private * > > *key. * > > ** > > *The OCSP certificate SHALL be signed by the CA issuing private key * > > *which corresponds to the issuing CA public key that is in this * > > *entry.* > > ** > > *When it receives an OCSP request, the OCSP responder SHALL handle * > > *exceptions according to section 2.3. * > > ** > > *If the OCSP request contains the name of a requestor, the OCSP * > > *responder SHALL verify whether there exists a locally defined rule * > > *which regulates access control.If this rule exists, it SHALL be * > > *followed.* > > ** > > *For each target certificate, the OCSP Responder SHALL verify * > > *whether both the hash of the issuer's DN and the hash of the issuer * > > *public key which are present in the OCSP request match with those * > > *from an entry.* > > ** > > *When there is no match, then the OCSP Responder SHALL indicate the * > > *"unknown" status and proceed with the next target certificate from * > > *the OCSP request.* > > ** > > *When there is a match, the OCSP Responder SHALL use the serial * > > *number of the target certificate this is present in the OCSP * > > *request to determine the revocation status of that certificate * > > *according to the method(s) indicated in the entry. * > > ** > > *When the revocation status is provided by the server using a real * > > *time access to a database of revocation statuses of issued * > > *certificates, then the thisUpdate field SHALL be present in the* > > *SingleResponse response whereas the nextUpdate field SHALL be * > > *missing. * > > ** > > *Otherwise, both the thisUpdate and the nextUpdate fields SHALL be * > > *present in the SingleResponse. * > > ** > > *The time at which this response will be signed MUST be indicated in * > > *the producedAt field from the SingleResponse.* > > ** > > *If a singleRequestExtensions is present in the request it MUST be * > > *processed.* > > ** > > *If there is another target certificate present in the request, it * > > *SHALL be processed in the same way.* > > ** > > *If a requestExtensions is present in the request it SHALL be * > > *processed.* > > ** > > *The OCSP response MUST be signed using the OCSP private key.* > > ** > > *Unless there is a local rule which states differently, for every * > > *target certificate which matches both with the hash of a CA DN > and an * > > *issuing public key from an entry, the OCSP certificate of that > entry * > > *SHALL be placed in the certs field.* > > ** > > *It may happen, that none of the target certificates from the OCSP* > > *request matches both with the hash of a CA DN and an issuing public * > > *key from an entry.In that case and unless a local rule states * > > *differently, the certs field from the BasicOCSPResponse SHOULD be * > > *kept empty (to limit the disclose of the names of the CAs from > which * > > *the OCSP Responder received a delegation from).* > > ** > > *1.3. Processing by a locally trusted Responder* > > ** > > *For each CA for which the locally trusted Responder is * > > *authoritative, the OCSP Responder SHALL maintain a list of entries. * > > ** > > *Each entry SHALL contain:* > > ** > > *- the URI associated to this OCSP Responder, from which the OCSP * > > *requests are received, * > > ** > > *- the DN from a CA,* > > ** > > *- an issuing public key from a CA,* > > ** > > *- the method(s) used to know for which subset of certificates * > > *issued by the CA it is responsible for, * > > ** > > *- the method(s) used to obtain the revocation status of that * > > *subset of certificates issued under that CA issuing public key,* > > ** > > *- the method used to gain access to the private key in order to * > > *sign the OCSP response. * > > ** > > *For a given URI value, the OCSP Responder SHALL only use one > private * > > *key.Therefore there cannot be two entries with the same URI value * > > *and a different method to gain access to the appropriate private > key.* > > ** > > *NOTE: a BasicOCSPResponse can only be signed using a single private * > > *key. * > > ** > > *When it receives an OCSP request, the OCSP responder SHALL handle * > > *exceptions according to section 2.3. * > > ** > > *If the OCSP request contains the name of a requestor, the OCSP * > > *responder SHALL verify whether there exists a locally defined rule * > > *which regulates access control.If this rule exists, it SHALL be * > > *followed.* > > ** > > *For each target certificate, the OCSP Responder SHALL verify * > > *whether both the hash of the issuer's DN and the hash of the issuer * > > *public key which are present in the OCSP request match with those * > > *from an entry.* > > ** > > *When there is no match, then the OCSP Responder SHALL indicate the * > > *"unknown" status and proceed with the next target certificate from * > > *the OCSP request.* > > ** > > *When there is a match, the OCSP Responder SHALL use the serial * > > *number of the target certificate this is present in the OCSP * > > *request to determine the revocation status of that certificate * > > *according to the method(s) indicated in the entry. * > > ** > > *When the revocation status is provided by the server using a real * > > *time access to a database of revocation statuses of issued * > > *certificates, then the thisUpdate field SHALL be present in the* > > *SingleResponse response whereas the nextUpdate field SHALL be * > > *missing. * > > ** > > *Otherwise, both the thisUpdate and the nextUpdate fields SHALL be * > > *present in the SingleResponse. * > > ** > > *The time at which this response will be signed MUST be indicated in * > > *the producedAt field from the SingleResponse.* > > ** > > *If a singleRequestExtensions is present in the request it MUST be * > > *processed.* > > ** > > *If there is another target certificate present in the request, it * > > *SHALL be processed in the same way.* > > ** > > *If a requestExtensions is present in the request it SHALL be * > > *processed.* > > ** > > *The OCSP response MUST be signed using the OCSP private key.* > > ** > > *The certs field may contain no, one or several OCSP certificates * > > *according to local rules followed by the locally trusted Responder.* > > > Not broken. > > /Stefan > > End of comments > > > Denis > > _______________________________________________ pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --------------030806070903090303090301 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1

Stefan,

 

I have finally reviewed your disposition of comments. I have used draft 13.

 

I will not address the comments in sequence, but I will consider four categories:

 

Category 1) Some comments which seem to be solved. Yes indeed, they may be a few of them !

 

Category 2) Some comments which might possibly be solved at the WG level.

 

Category 3) Some comments that I will address at the IETF last call level, rather than the WG last call level, since I disagree
that it is “new ways to say the same thing” and it is likely to be a waste of time for both of us to argue again at the WG level
(these comments are commented as “not broken”).

 

Category 4) Some typos and editorials found while reading draft 13.

 

 

CATEGORY 1

 

Comment 4 (was editorial).

 

Comment 5.

 

Comment 6.

 

Comment 19. Solved, since “unknown” seems now to be also allowed for non-issued certificates
(even if the OCSP responder is using a direct access to the certificate database). See comment 8.

 

Comment 13: Acceptable, since the text uses “MAY”.

 

Comment 18.

 

Comment 22.

 

Comment 23.

 

Comment 28.

 

CATEGORY 1

 

Comment 8: You have changed the meaning of the revoked state in a way that is not what I requested.

 

The original text was:

 

   The "revoked" state indicates that the certificate has been revoked

   (either permanantly or temporarily (on hold)).

 

The new text is:

 

   The "revoked" state indicates that the certificate has been revoked
   either permanently or temporarily on hold (i.e. the revocation reason
   is certificateHold).

 

By doing this, you do not allow any other case in the future to have a temporary revocation: “temporarily on hold”
is not the same as “temporarily revoked”.

 

I propose the following rewording:

 

   The "revoked" state indicates that the certificate has been revoked 

   either permanently or temporarily (e.g. placed on hold).

 

The way the text from draft 13 is now written seems to allow using either “unknown” or “revoked” for non-issued certificates.
If this is the intent, then the good news is that this does not come anymore into conflict with the French rules which apply for
the Administration since OCSP responders from CAs used by the French Ministries having a direct access to the database
of issued certificates will be able to use “unknown”, rather than “revoked” and the reason code “onhold”.

 

However, the current text is still mandating the use of Extended Revoked Definition, but the rational for its need it is very poor.
As I have said on the PKIX list, the fact that the revocation date is January 1rst, 1970 is fully sufficient to know that we are in that
very special case, and you have not provided a rational to say the contrary.

 

So we could get rid of it, … but the text from section 4.4.8 states:

 

   This extension MAY be present in other responses to signal that the
   responder implements the extended revoked definition in section 2.2.

 

I have difficulties to understand what is really meant there (“other responses” ?), since the text states:

 

   This extension indicates that the responder supports the extended
   definition of the "revoked" status to also include non-issued
   certificates according to section 2.2.

 

Since both “unknown” and revoked” can be used, it would be desirable to be able to include the same extension in both cases,
but in that case that extension should be renamed.

 

I would propose to rename it: "non-issued certificate” which means that the associated CA has no record of ever having issued
a certificate with the certificate serial number in the request (I still consider it as unnecessary in the case of “revoked”, but it would be
very useful in the case of “unknown”). Of course, the text from section 4.4.8 would need to be revised.

 

I propose the following:

 

4.4.8  Non-issued certificate extension
 
   This extension MUST be included in the OCSP response when the OCSP 
   responder knows that the CA identified in the request has no record 
   of ever having issued a certificate with the certificate serial 
   number indicated in the request.
 
   Clients do not have to parse this extension in order to determine 
   the status of certificates in responses.
 
   This extension is identified by the object identifier id-pkix-ocsp-
   non-issued-cert.
 
     id-pkix-ocsp-non-issued-cert OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}
 
   The value of the extension SHALL be NULL. This extension MUST NOT be
   marked critical.

 

Then the text on page 8 would need to be rearranged.

 

The current text is:

 

   This state MAY also be returned if the
   associated CA has no record of ever having issued a certificate with
   the certificate serial number in the request, using any current or
   previous issuing key (referred to as a "non-issued" certificate in
   this document).
 
   The "unknown" state indicates that the responder doesn't know about
   the certificate being requested.
 
   NOTE: The "revoked" state for known non-issued certificate serial
         numbers is allowed in order to reduce the risk of relying
         parties using CRLs as a fall back mechanism, which would be
         considerably higher if an "unknown" response was returned.
 
   When a responder responds revoked to a status request for a non-
   issued certificate, the responder MUST include the extended revoked
   definition response extension (section 4.4.8) in the response,
   indicating that the OCSP responder supports the extended definition
   of revoked state to also cover non-issued certificates. In addition,
   the SingleResponse related to this non-issued certificate;
 
    - MUST provide the revocation reason certificateHold (6),
 
    - MUST specify the revocationTime January 1, 1970, and;
 
    - MUST NOT include a CRL References extension (section 4.4.2) or any
      CRL Entry Extensions (section 4.4.5).

 

Proposed text for a replacement:

 

   The "unknown" state indicates that the responder doesn't know about
   the certificate being requested.
 
   If the OCSP responder knows that CA identified in the request has 
   no record of ever having issued a certificate with the certificate 
   serial number in the request, using any current or previous issuing 
   key (referred to as a "non-issued" certificate in this document), 
   the OCSP responder SHALL respond either “revoked “ or “unknown”.
 
   Note: The "revoked" state for known non-issued certificate serial 
   numbers is allowed in order to reduce the risk of relying parties 
   using CRLs as a fall back mechanism, which would be possible when 
   the "unknown" response is returned.
 
   When a responder responds revoked or unknown to a status request 
   for a non-issued certificate, the responder MUST include the 
   non-issued certificate extension (see section 4.4.8) in the 
   response. 
 
   When a responder responds revoked to a status request for a non-
   issued certificate, in addition, the responder:
 
    - MUST provide the revocation reason certificateHold (6),
 
    - MUST specify the revocationTime January 1, 1970, and;
 
    - MUST NOT include a CRL References extension (section 4.4.2) or any
      CRL Entry Extensions (section 4.4.5).

 

Finally, the last bullet on page 4 should be reworded:

 

Current text:

 

      o Section 4.4.8 specifies a new extension that indicates that the
         responder supports the extended use of the "revoked" response
         for non-issued certificates defined in section 2.2.

 

Proposed replacement text:

 

      o  Section 4.4.8 specifies a new extension that indicates that 
         the OCSP responder knows that CA identified in the request 
         has no record of ever having issued a certificate with the 
         certificate serial number present in the request, as defined 
         in section 2.2.

 

Comment 9: Solved, if the comment above may be solved.

 

Comment 20:  This comment is preliminary classified by you as “not broken”. However, since you asked: “If you don’t replace 4.2.2.3,
then what really are you missing ?”, I will provide you with an answer.

 

This is the wrong way to state the question. Providing an ASN.1 syntax as in 4.2.1 is not enough: the use of every parameter
MUST be explained using English words. So if you explain the use of every parameter after the description of the ASN.1 syntax
in section 4.2.1. then section 4.2.2.3 is no more needed and thus can be deleted.

 

The answer to your question “what is really missing” is a description of the use of every parameter listed in the ASN.1 in section 4.2.1

 

Comment 21.

 

While I can agree in general with the intent of the text, I do not understand the first sentence of the Note which speaks of “CA key rollover”
and is copied below:

 

   Note: CA key rollover is not prohibited when issuing a certificate
         for an authorized responder for backwards compatibility with
         RFC 2560 [RFC2560]. That is, it is not prohibited to issue a
         certificate for an authorized responder using a different
         issuing key than the key used to issued the certificate being
         checked for revocation. However, such practice is strongly
         discouraged since clients are not required to recognize a
         responder with such certificate as an authorized responder.

 

I would propose to delete it, since it does not add anything and thus to have:

 

   Note: For backwards compatibility with RFC 2560 [RFC2560], it is 
         not prohibited to issue a certificate for an authorized 
         responder using a different issuing key than the key used to 
         issued the certificate being checked for revocation. 
         However, such practice is strongly discouraged since clients 
         are not required to recognize a responder with such 
         certificate as an authorized responder.

 

Comment 24: The ASN.1 module in annex B.1 is still wrong, since it does not define NoCheck.

 

Comment 26: You asked for explanations. Let me provide you with an example when CRLs are being used by the OCSP responder
in the background. The OCSP responder needs to make sure that the CRL it uses is valid. If it is simply using published CRLs
(i.e. no trusted link with the CA), it needs to make sure that the CA which has issued the CRL has no been revoked.

 

In France, there is a root CA for the Administration. However, the use of that root CA is optional. Thus a Ministry may have its own root,
but may also have its key certified by the root CA of the Administration. The OCSP responder may use the root CA of the Ministry,
while a relying party may use the root CA of the Administration (or the reverse) to validate the CRL for the target certificate.
Thus the revocation status will be different if the certificate of the CA of the Ministry is revoked by the root CA of the Administration.

 

CATEGORY 3

 

Comments 2, 3, 7, 10, 12, 14, 15, 16, 17, 25 and 27.

 

 

CATEGORY 4

 

Page 4. The indentation of the bullets in section 1 is not uniform.
Bullets 1, 4, 5 and 9 have problems.

 

Page 4. The fact that there is now an Annex B.2 dealing with the 2008 ASN.1 syntax is missing. This should be added.

 

Page 10. Change “Se further section 4.2.2.2” into “See further section 4.2.2.2”


Denis

 

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


Denis,

Responding to your comments below.

However, one general remark to make recurring comments easier to understand.

The WG decided to adopt a minimalistic approach to updating RFC 2560. That means that 
  1. We don't change anything from RFC 2560 unless it is broken, or the industry clearly need clarifications in order to avoid interoperability issues.
  2. We retain the document structure of RFC 2560 as much as possible to allow easy comparison of what the changes are in comparison with RFC 2560.

One can always think up more clever ways to write things out in words. But that also comes with a risk.
The current words has been around for a long time and we know from experience which words worked to produce working implementations, and which did not.
Introducing new ways to say the same thing may introduce new problems and people might disagree on what the new perfect wording should be. And this could go on forever.

So when my reply is "Not broken", then that is because the current wording does not have such problems that is merits a change.



From: Denis Pinkas <denis.pinkas@bull.net>
Date: Sunday, January 20, 2013 5:12 PM
To: Stefan Santesson <stefan@aaa-sec.com>, Stephen Kent <kent@bbn.com>
Cc: pkix <pkix@ietf.org>
Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC

Please find 32 comments on draft-ietf-pkix-rfc2560bis

 

1. The document states:

 <Cut away issue 1 regarding authorship etc, as it has been responded to separately>

Responded to separately.


                
 

                
 

                
2. The
                    current text from section 2 states:

                
 

                
2.  Protocol Overview

                
 

                
   In lieu of or as a supplement to checking against a periodic CRL, it

                
   may be necessary to obtain timely information regarding the

                
   revocation status of a certificate (cf. RFC5280], Section 3.3).

                
   Examples include high-value funds transfer or large stock trades.

                
 

                
   The Online Certificate Status Protocol (OCSP) enables applications to

                
   determine the (revocation) state of an identified certificate. OCSP

                
   may be used to satisfy some of the operational requirements of

                
   providing more timely revocation information than is possible with

                
   CRLs and may also be used to obtain additional status information. 

                
 

                
This text is misleading because readers may think that OCPS necessarily provides “timely information”.

                
 

              

          

        

      
      


      

      
"may" does not
        mean "necessarily".

      


      

      
        

          

            

                
Proposed text replacement:

                
 

                
   The Online
                      Certificate Status Protocol (OCSP) is a
                      client-server 

                
   protocol
                      which enables applications to obtain the
                      revocation status 

                
   of one or
                      more certificates either "good", "revoked", or
                      "unknown".

                
 

                
   The
                      revocation status may be provided by the server
                      either using a 

                
   real time
                      access to a database of issued certificates, or
                      using a 

                
   batch access
                      to a database of issued certificates, or using a 

                
   real time
                      access to a database of revocation statuses of
                      issued 

                
   certificates,
                      or using a batch access to a database of
                      revocation 

                
   statuses of
                      issued certificates, or using CRLs, or using a 

                
   combination
                      of base CRLs and delta CRLs.

                
 

                
   In the first
                      case, it is possible to obtain timely revocation
                      status 

                
   information,
                      whereas in the other cases, the freshness of the 

                
   revocation
                      status is not better than the mechanisms it is
                      based on.

                
 

                
 

              

          

        

      
      


      

      
Not broken

      


      

      
        

          

            

                
3. The
                    current text from section 2 states:

                
 

                
   An OCSP client issues a status request to an OCSP responder and 

                
   Suspends acceptance of the certificate in question until the 

                
   responder provides a response.

                
 

                
   This protocol specifies the data that needs to be exchanged between

                
   an application checking the status of a certificate and the server

                
   providing that status.

                
 

                
Thus is insufficient for an overview. More details are needed to know what the document provides, 
in particular that the request may contain several requests for several certificates issued by different CAs. 
The possibility of using extensions should also be advertised.

                
 

                
Proposed text replacement:

                
 

                
   When using
                    OCSP, an OCSP client issues a certificate revocation
                    

                
   status request
                    to an OCSP responder for one or
                      more certificates 

                
   issued by
                      the same CA or for one or more certificates issued
                      by 

                
   different
                      CAs and
                    then suspends acceptance of the certificate(s) 

                
   in question
                    until the responder provides a response.

                
 

                
   This document
                    specifies the data that needs to be exchanged
                    between

                
   an application
                    checking the status of a certificate and the server

                
   providing that
                    status.  

                
 

                
   OCSP may
                      also provide additional status information using 

                
   extensions.
                      

                
 

                
 

              

          

        

      
      


      

      
Not broken

      


      

      
        

          

            

                
4. Page
                    6. Editorial. Punctuation and a CR/LF are missing.

                
 

                
The
                    text states:

                
 

                
   3. the request contains the information needed by the responder If

                
      any one of the prior conditions are not met, the OCSP responder

                
      produces an error message; otherwise, it returns a definitive

                
      response.

                
 

                
It
                    should state:

                
 

                
   4. the request contains the information needed by the responder.

                
 

                
      If any one of the prior conditions are not met, the OCSP responder

                
      produces an error message; otherwise, it returns a definitive

                
      response.

                
 

                
 

              

          

        

      
      


      

      
Fixed in draft 10.

      


      

      
        

          

            

                
5. On
                    page 7, the text states:

                
 

                
   All
                      definitive response messages SHALL be digitally
                      signed. The key

                
   used to sign
                      the response MUST belong to one of the following:

                
 

                
   -  the CA who issued the certificate in question

                
   -  a Trusted Responder whose public key is trusted by the requester

                
   -  a CA Designated Responder (Authorized Responder) who holds a

                
      specially marked certificate issued directly by the CA, indicating

                
      that the responder may issue OCSP responses for that CA.

                
 

                
The
                    paragraph is ambiguous on several aspects. 

                
 

                
Delegation

                    is addressed in at least three different places, but
                    with different terms and conditions. 

                    If some one picks a sentence in one paragraph rather
                    than another, it will lead to a different
                    conclusion. 

                    RFCs are supposed to be clear.

                
 

                
On
                    page 10, the current text states in section 2.6 OCSP
                      Signature Authority Delegation states:

                
 

                
   The
                        key that signs a certificate's status
                        information need not be the

                
   same

                      key that signed the certificate. A
                      certificate's issuer

                
   explicitly
                      delegates OCSP signing authority by issuing a
                      certificate

                
   containing a
                      unique value for extendedKeyUsage in the OCSP
                      signer's

                
   certificate.
                      This certificate MUST be issued directly to the

                
   responder by
                      the cognizant CA.

                
 

                
On page
                    16, there is a section 4.2.2.2 called “Authorized
                      Responders”
                    dealing with the same topic. 

                
 

                
Section
                    4.2.2.2 states:

                
 

                
   The
                        key that signs a certificate's status
                        information need not be the

                
   same

                      key that signed the certificate. It
                      is necessary however to

                
   ensure that
                      the entity signing this information is authorized
                      to do

                
   so.  Therefore, a
                      certificate's issuer MAY either sign the OCSP

                
   responses
                      itself or it MAY explicitly designate this
                      authority to

                
   another
                      entity.  OCSP

                      signing delegation SHALL be designated by the

                
   inclusion of
                      id-kp-OCSPSigning in an extendedKeyUsage
                      certificate

                
   extension
                      included in the OCSP response signer's
                      certificate.  This

                
   certificate
                      MUST be issued directly by the CA that issued the

                
   certificate
                      in question.

                
 

                
   The CA
                      SHOULD use the same issuing key to issue a
                      delegation

                
   certificate
                      as was used to sign the certificate being checked
                      for

                
   revocation.
                      Systems

                        relying on OCSP responses MUST recognize a

                
   delegation

                      certificate as being issued by the CA that issued
                      the

                
   certificate

                      in question only if the delegation certificate and
                      the

                
   certificate

                      being checked for revocation was signed by the
                      same key.

                
 

                
The
                    last sentence above in yellow is the key sentence
                    that is missing in the two other sections.

                
 

                
Most implementations only support the case where the OCSP Responder receives an OCSP certificate that is signed by the same key 
that was used to sign the target certificate. They do not support the case where the OCSP Responder receives an OCSP certificate 
that is signed by a key that is different from the one that was used to sign the target certificate.

                
 

                
It is
                    inappropriate to have three sections dealing with
                    the same topic with a slightly different meaning.

                
 

                
It is
                    proposed the following.

                
 

                
On page
                    7, after:

                
 

                
   -  a CA Designated Responder (Authorized Responder) who holds a

                
      specially marked certificate issued directly by the CA, indicating

                
      that the responder may issue OCSP responses for that CA.

                
 

                
it is
                    proposed to add “(see
                      section 4.2.2.2 for further details)”, so
                    that the reader knows that more details are provided
                    later on.

                
 

                
Then
                    we do not need two sections to address delegation
                    which start with the same sentence: 

                  

                


                    “The key that
                      signs a certificate's status information need not
                      be the same key that signed the certificate”.

                
 

                
It is
                    thus proposed to delete section 2.6.

                
 

                
Section
                    4.2.2.2 will thus remain the single section
                    providing full details.

                
 

                
 

              

          

        

      
      


      

      
I have added
        references to section 4.2.2.2 in the quoted sections in 2.2 and
        2.6.

      
(will be included
        in draft 11)

      


      

      


      

      
        

          

            

                
6. Page 7, the text states:

                
 

                
   A definitive response message is composed of:

                
 

                
   -  version of the response syntax

                
   -  name of the responder

                
   -  responses for each of the certificates in a request

                
   -  optional extensions

                
   -  signature algorithm OID

                
   -  signature computed across hash of the response

                
 

                
This
                    description does not fit with the ASN.1 syntax which
                    is detailed later on, and in particular:

                
 

                
   ResponseData ::= SEQUENCE {

                
      version              [0] EXPLICIT Version DEFAULT v1,

                
      responderID              ResponderID,

                
      producedAt               GeneralizedTime,

                
      responses                SEQUENCE OF SingleResponse,

                
      responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

                
 

                
Proposed text replacement:

                
 

                
   A definitive
                      response message is composed of:

                
 

                
   - a response
                      status and if there is no error, the following:

                
   - the
                      version of the response syntax,

                
   - an
                      identifier of the OCSP server,

                
   - the time
                      at which the response was produced,

                
   - single
                      responses for each of the target certificates,

                
   - optional
                      extensions,

                
   - the
                      signature algorithm OID,

                
   - the
                      signature computed across hash of the response,
                      and

                
   - optional
                      certificates.

                
 

                
 

              

          

        

      
      


      

      
This is an
        overview section. We ought not try to duplicate the level of
        detail provided in the detailed protocol section.

      
A "definitive
        response" according to tho 2.1 is a response to an error-free
        request, so your first remark is redundant.

      


      

      
I have added a
        note about time to the current list, and changed "name" to
        identifier in bullet 2. 

      
(will be included
        in draft 11)

      


      

      
        

          

            

                
7. The
                    text states on page 7:

                
 

                
   The response
                      for each of the certificates in a request consists
                      of

                
 

                
   -  target
                      certificate identifier

                
   -  certificate
                      status value

                
   -  response
                      validity interval

                
   -  optional
                      extensions

                
 

                
However,

                    there are no explanations for the purpose of these
                    parameters and how they should be processed.

                
There
                    are also no explanations on how to process a single
                    response and how to verify that it is its presence
                    within the signed structure 

                    is valid or not valid. This is a major deficiency of
                    the current description of RC 2560 where there is no
                    explanation on how to validate 

                    a single response.

                
 

                
Text
                    proposal to be added after:

                
 

                
   The purpose
                      of the identifier of the OCSP server is to allow
                      OCSP 

                
   clients to
                      find whether the definitive response was signed by
                      a CA 

                
   or by an
                      OCSP Responder.

                
 

                
   The
                      identifier of the OCSP server SHOULD either be the
                      name or the 

                
   key from a
                      CA, or the name or the key from a OCSP Responder.

                
 

                
   Unless there
                      exist local rules (which are outside the scope of
                      this 

                
   document)
                      for verifying that a single response is correctly
                      signed, 

                
   the
                      following applies:

                
 

                
   When the
                      identifier matches with the name of the CA which
                      has issued 

                
   the target
                      certificate or corresponds to the key used to
                      issue the 

                
   target
                      certificate, then a single response is correctly
                      signed 

                
   only if the
                      digital signature of the OCSP response is valid
                      using the 

                
   key used to
                      sign the target certificate.

                
 

                
   When the
                      identifier does not match with the name of the CA
                      which has 

                
   issued the
                      target certificate or does not correspond to the
                      key used 

                
   to issue the
                      target certificate, then an single response is
                      correctly 

                
   signed only
                      if :

                
 

                
         (a)
                      there exists in the response an OCSP certificate
                      issued by 

                
             the
                      CA which has issued the target certificate which
                      is 

                
             signed
                      by the same key as the one used to issue the 

                
             target

                      certificate, and

                
 

                
         (b)
                      the digital signature of the OCSP response is
                      valid using 

                
             the

                      subjectPublicKey contained in this OCSP
                      certificate.

                
 

                
 

              

          

        

      
      


      

      
Not broken.

      
All of this is
        already covered by the document.

      


      

      
        

          

            

                
8. The
                    text states on page 7:

                
 

                
   The "revoked"
                    state indicates that the certificate has been
                    revoked

                
   (either
                      permanently or temporarily (on hold)). This
                    state MAY also be

                
   returned if
                    the responder knows that the requested certificate
                    has

                
   never been
                      issued during the history of the associated CA using

                    any

                
   current or
                    previous issuing key. 

                
 

                
The
                    text is ambiguous because there are two embedded
                    parenthesis and it is unclear whether the inner
                    parenthesis means “i.e” or “e.g”. 

                    This single sentence may let think that on hold is
                    the single case for temporarily revocation. Since
                    neither X.509 nor RFC 5280 address 

                    the case of a temporary revocation in the context of
                    an OCSP response (but only in the context of CRLs),
                    we are able to add another case 

                    of temporary revocation which will only apply in the
                    context of OCSP.

                
 

                
The
                    above sentence using the terms “never
                      been issued during the history of the associated
                      CA “does
                    not capture the fact 

                    that it could be issued in the future, hence why
                    using “not yet been used” would
                    be more appropriate.

                
 

                
Finally,
                    it would have been more logical to use “unknown”. So
                    it is important to add a note to explain why we have
                    chosen that case for “legacy clients”, 

                    otherwise the people who have not participate to the
                    exchanges will not understand.

                
 

                
Proposed text replacement:

                
 

                
   The "revoked" state indicates that the certificate has been revoked,

                
   either permanently or temporarily.

                
 

                
   A certificate may be temporarily revoked either because it is 

                
   placed on hold (i.e. the revocation reason is certificateHold) or 

                
   because the responder is able to know, using a positive list of 

                
   issued certificates, that the serial number from the requested 

                
   certificate has not yet been used by the CA to issue a certificate 

                
   (i.e. the revocation reason is notIssuedOrIrregularlyIssued).

                
 

                
NOTE: The "revoked" state is used rather than the “unknown” state, to

                
      make sure that relying parties that were conformant to RFC 2560

                
      will not use CRLs as a fall back mechanism. 

                
 

              

          

        

      
      


      

      
I removed the
        double parenthesis and adopted your clarification with regard to
        "on hold". 

      


      

      
The text in draft
        10 has changed from what you have commented on. I believe that
        text is better.

      


      

      
You "Note" has
        problems.

      
    
        
  1. We do not prevent responders to respond "unknown" if their
          assessment is that this is an appropriate response,
          considering what they know about the requested serial number.
          Thus the term "is used" is misleading.
    2. 
        
  2. This mechanisms does not "make sure" that the clients do
          anything. It's up to the discretion of the relying party to
          decide what source of revocation checking they rely on. This
          does however reduce the risk of clients falling back to CRL:s
    3. 
        
  3. This mechanism is not just relevant to old clients, but also
          to new one for the same reason.
    4. 
      

      


      

      
I have adopted a
        modified version of your Note:

      


      

      

        
   NOTE: The "revoked" state for
            known non-issued certificate serial

        
         numbers is allowed in
            order to reduce the risk of relying

        
         parties using CRLs as a
            fall back mechanism, which would be

        
         considerably higher if an
            "unknown" response was returned.

      

      


      

      


      

      


      

      
        

          

            

                
 

                
9. The
                    text states on page 8:

                
 

                
   When a
                      responder responds revoked to a status request for
                      a non-

                
   issued
                      certificate, the responder MUST also;

                
 

                
    - include
                      the extended revoked definition response extension

                
      (section
                      4.8), indicating that the OCSP responder supports
                      the

                
      extended
                      definition of revoked state to also cover
                      non-issued

                
      certificates,

                
 

                
    - provide
                      the revocation reason certificateHold (6), and;

                
 

                
    - specify
                      the revocation date January 1, 1970. 

                
 

                
As
                    already explained on the PKIX list, using the
                    revocation reason certificateHold is not appropriate 

                    because it changes the meaning of certificateHold. 

                
 

                
The
                    extended revoked definition response extension is a
                    means to signal that it not a true certificate hold
                    but a “not issued certificate”. 

                    Legacy applications cannot take advantage of it. 

                
 

                
Some
                    applications which handle non repudiation enter a
                    waiting state when the revocation reason
                    certificateHold is used thus 

                    it is not appropriate to overload the meaning.

                
 

                
It is
                    possible to use another enumeration for signalling
                    that specific case:

                
notIssuedOrIrregularlyIssued

                    (7).

                
 

                
Thus
                    for new applications it would be much better to use
                    notIssuedOrIrregularlyIssued (7) as already proposed
                    on the PKIX list.

                
 

                
The above sentence uses the text: 

                
 

                
“a status request for a non-issued certificate” 

                
 

                
whereas it would be more appropriate to state: 

                
 

                
“a status request for a serial number which has not been used by the CA or used irregularly to issue a certificate”.

                
 

                
Placing the ASN.1 description at such a place in the document is inappropriate since the ASN.1 structures have not yet been described. 
Thus only the functional aspects should be mentioned, but not the ASN.1 implications.

                
 

                
BTW, the description should follow the same order as the ASN.1. This is not the case. 

                
 

                
This text should be deleted from this section and the appropriate text should be added when the parameters of the response are described. 

                
 

                
The text proposed in the previous comment should be sufficient at this time of reading.

                
 

                
In
                    addition, section
                      4.4.8  Extended

                      Revoked Definition should be deleted.

                
 

                
 

              

          

        

      
      


      

      
The referred text has been updates in draft 09.

      


      

      
This has been discussed on the list and you have yet to
        convince the list of your new reason code.

      
I disagree as the risk of running into problems with the
        deployed base of application is hugely larger with introduction
        of a new reason code, rather than using certificateHold.

      
No application should be broken, since no application have
        business asking for non-issued cert serial numbers in the first
        place. Secondly, no application can assume that a
        certificateHold reason will be cleared any time soon.

      


      

      


      

      
        

          

            

                
10. The
                    text states on page 8:

                
 

                
2.4  Semantics of
                      thisUpdate, nextUpdate and producedAt

                
 

                
This
                    section is misplaced. At this time of reading, the
                    reader does not know that thisUpdate, nextUpdate and
                    producedAt are values 

                    used by the ASN.1 structures. It is appropriate to
                    describe what theses parameters mean when the ASN.1
                    syntax is described. 

                    The current ASN.1 syntax is very badly described.
                    One would expect that after every ASN.1 structure
                    description every parameter is described. 

                    Unfortunately this is not the case. 

                    

                
The
                    text from this section is not aligned with the text
                    that is present in section 4.2.2.1. 

                
 

                
In
                    particular, in section 2.4:

                
 

                
   If
                      nextUpdate is not set, the responder is indicating
                      that newer

                
   revocation
                      information is available all the time.

                
 

                
While
                    in section 4.2.2.1:

                
 

                
   Responses
                      where the nextUpdate value is not set are
                      equivalent 

                
   to a CRL
                      with no time for nextUpdate (see Section 2.4).

                
 

                
It is
                    not appropriate to have two different descriptions
                    in two different places.

                
 

                
Delete
                    section 2.4. See comment number 19 for the
                    description of these parameters.

              

          

        

      
      


      

      
Not broken.

      
The current text segments fits well into a protocol overview
        section.

      


      

      
        

          

            

                
 

                
 

                
11.
                    Section 2.5 is also misplaced. They use values from
                    the ASN.1 syntax which has not yet been described. 

                    They should be moved or incorporated in the document
                    once the ASN.1 description has been done.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
 

                
12.
                    Remainder: Section 2.6 should be deleted (see
                    comment number 5).

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
 

                
13.
                    Section 2.7 states:

                
 

                
2.7  CA Key
                      Compromise

                
 

                
   If an OCSP
                      responder knows that a particular CA's private key
                      has

                
   been
                      compromised, it MAY return the revoked state for
                      all

                
   certificates
                      issued by that CA.

                
 

                
This
                    section is misleading and should be removed. The
                    reason is the following:

                
 

                
The
                    relying party must verify that the singleResponse is
                    signed by a responder which is entitled to do so.

                
 

                
a) If
                    the CA key has been compromised and if the response
                    is signed by that CA key then the singleResponse
                    will be discarded 

                    when performing the certification path validation whatever
                      the content of the response may be.

                
 

                
b) If
                    the CA key which has issued the OCSP certificate has
                    been compromised and if the response is signed by
                    the key present 

                    in the OCSP certificate then the singleResponse will
                    be discarded when performing the certification path
                    validation

                    whatever the content of the response may be.

                
 

                
 

                
Security

                    must be provided using the validation of the
                    certification path. Thus it does not matter what the
                    OCSP responder states.

              

          

        

      
      


      

      


      

      
Not broken.

      
An OCSP responder does not have to be chained to the broken
        CA. The relying party may have other trust configuration at
        choice.

      


      

      


      

      
        

          

            

                


                

                
 

                
14. The
                    text states on page 11:

                
 

                
3.2  Signed
                      Response Acceptance Requirements

                
 

                
   Prior to
                      accepting a signed response as valid, OCSP clients
                      SHALL

                
   confirm
                      that:

                
 

                
   1. The
                      certificate identified in a received response
                      corresponds to

                
      that
                      which was identified in the corresponding request;

                
 

                
   2. The
                      signature on the response is valid;

                
 

                
   3. The
                      identity of the signer matches the intended
                      recipient of the

                
      request.

                
 

                
   4. The
                      signer is currently authorized to sign the
                      response.

                
 

                
   5. The time
                      at which the status being indicated is known to be

                
      correct
                      (thisUpdate) is sufficiently recent.

                
 

                
   6. When
                      available, the time at or before which newer
                      information will

                
      be
                      available about the status of the certificate
                      (nextUpdate) is

                
      greater
                      than the current time.

                
 

                
This
                    section is misplaced since it uses terms from the
                    ASN.1 syntax and the protocol description has not
                    yet been made, 

                    since it is the next section 4. Its text is not
                    correct either. 

                
 

                
This
                    description does not take into account the fact that
                    a BasicOCSPResponse may
                    contain one or several SingleResponses. 

                    In particular, the sentence “The signer is currently
                      authorized to sign the response” is
                    misleading because a signer 

                    may be authorized to include some SingleResponses but not
                    necessarily all of them. 

                
 

                
The
                    appropriate explanations should be done after the
                    description of the response, when describing the
                    processing of the response.

                
 

                
Delete
                    that section.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
 

                
15. On
                    page 12, after the ASN.1 description, the only
                    parameters which are described are: 

                
hashAlgorithm, issuerNameHash,

                      issuerKeyHash and serialNumber.

                
 

                
This
                    is insufficient.  In
                    order to cover the full list of parameters, the
                    following text is proposed:

                
 

                
   requestorName
                      is optional and MAY be used by the server for
                      access 

                
   control and
                      audit purposes.

                
 

                
   requestList
                      contains one or more single requests.

                
 

                
   requestExtensions
                      is OPTIONAL.  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.

                
 

                
   reqCert
                      contains the identifier of a target certificate.

                
 

                
   issuerNameHash
                      is the hash of the Issuer's distinguished name.  The 

                
   hash shall
                      be calculated over the DER encoding of the
                      issuer's name 

                
   field in the
                      certificate being checked. 

                
 

                
   issuerKeyHash
                      is the hash of the Issuer's public key.  The hash 

                
   shall be
                      calculated over the value (excluding tag and
                      length) of the 

                
   subject
                      public key field in the issuer's certificate.  The hash 

                
   algorithm
                      used for both these hashes, is identified in 

                
   hashAlgorithm.
                      

                
 

                
      The primary
                      reason to use the hash of the CA's public key in 

                
      addition
                      to the hash of the CA's name, to identify the
                      issuer, 

                
      is that
                      it is possible that two CAs may choose to use the
                      same 

                
      name
                      (uniqueness in the Name is a recommendation that
                      cannot be 

                
      enforced).

                      Two CAs will never, however, have the same public
                      key 

                
      unless
                      the CAs either explicitly decided to share their
                      private 

                
      key, or
                      the key of one of the CAs was compromised.

                
 

                
   serialNumber
                      is the serial number of the certificate for which
                      

                
   status is
                      being requested.

                
 

                
   singleRequestExtensions

                      is OPTIONAL.  Any

                      specific extension is 

                
   OPTIONAL.  The critical
                      flag SHOULD NOT be set for any of them. 

                
 

                
   The
                      requestor MAY choose to sign the OCSP request.  In that case,
                      the

                
   signature is
                      computed over the tbsRequest structure.  If the
                      request

                
   is signed,
                      the requestor SHALL specify its name in the
                      requestorName

                
   field.  Also, for
                      signed requests, the requestor MAY include

                
   certificates
                      that help the OCSP responder verify the
                      requestor's

                
   signature in
                      the certs field of Signature.

                
 

              

          

        

      
      


      

      
Not broken.

      
The current text is short, but it is actually sufficient from
        the context of the ASN.1 definitions of the section. This is a
        detailed protocol section and the reader need to understand
        ASN.1 in any case to understand and implement the section.

      
The information about criticality is already covered in the
        extension section.

      


      

      


      

      
        

          

            

                
 

                
16.
                    Section 4.1.2 is called: “Notes on the
                      Request Syntax”

                
 

                
The
                    first paragraph has been moved after the description
                    of issuerKeyHash and
                    thus is no more needed.

                
 

                
The
                    second paragraph has been moved after the
                    description of requestExtensions. 

                    However, the sentence 

                    “ Unrecognized extensions MUST
                      be ignored (unless they have the critical flag set
                      and are not understood)” 

                    has been deleted since it applies to the OCSP
                    responder and not to the OCSP client. Thus it is no
                    more needed.

                
 

                
The
                    third paragraph applies to signed requests. However,
                    it should belong to a section dedicated on how
                    clients should build OCPS requests, 

                    which is currently missing. See the next comment.

                
 

                
This
                    section should be deleted.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
 

                
17. There
                    should be a new section called: “Requirements

                      for OCSP clients”. 

                
 

                
It is
                    important first to re-advertise that the request may
                    be about several certificates. 

                    Thus it is important to describe the process for
                    building a request, which is currently missing.

                
 

                
   An OCSP
                      request allows getting in the same response the
                      revocation 

                
   status of
                      one or more certificates.  In order to
                      request the 

                
   status of
                      one or more certificates in a single request, OCSP
                      

                
   clients
                      SHALL follow the following rules :

                
 

                
   For each
                      candidate certificate, OCSP clients SHALL verify 

                
   whether
                      there exists a locally defined rule for the
                      certificate in 

                
   question
                      which indicates the URI where the OCSP responder
                      is 

                
   located.  If this rule
                      exists, it SHALL be followed. 

                
 

                
   Otherwise,
                      OCSP clients SHALL determine whether the candidate
                      

                
   certificate
                      contains an AIA extension with an accessMethod
                      which 

                
   contains the
                      id-ad-ocsp OID.  If

                      it is the case, the accessLocation 

                
   contains a
                      uniformResourceIdentifier (URI) which indicates
                      the 

                
   location of
                      the OCSP server for that certificate. 

                
 

                
   Certificates
                      that contain the same URI MAY be grouped in a
                      single 

                
   request.

                
 

                
Note:  For each
                      candidate certificate, when performing the path 

                
       validation

                      algorithm, the OCSP client SHOULD verify that the
                      

                
       current
                      time is within the validity period of the target 

                
       certificate.  Certificates
                      which are outside their validity 

                
       period
                      SHOULD NOT be included in the request.

                
 

                
   The
                      requestor MAY choose to sign the OCSP request. In
                      that case, the

                
   signature is
                      computed over the tbsRequest structure. If the
                      request

                
   is signed,
                      the requestor SHALL specify its name in the
                      requestorName

                
   field. Also,
                      for signed requests, the requestor MAY include

                
   certificates
                      that help the OCSP responder verify the
                      requestor's

                
   signature in
                      the certs field of Signature.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
Your text may provide guidance that could be useful to some
        implementers, but is completely beyond this document and
        further, not generally applicable or true.

      
As an example, an organisation may setup an in house locally
        configured OCSP responder that responds to all certificates "out
        there" that is relevant to that organisation.

      
Such clients would just blindly send OCSP requests to their
        local responder, disregarding any information in the cert.

      
It's totally beyond this spec to have an opinion about this.

      


      

      


      

      
        

          

            

                
 

                
18. The
                    text states on page 14:

                
 

                
   The
                      responder MAY include certificates in the

                
   certs field
                      of BasicOCSPResponse that help the OCSP client
                      verify the

                
   responder's
                      signature. If no certificates are included then
                      certs

                
   SHOULD be
                      absent.

                
 

                
While
                    this sentence is true, it is not sufficient. In
                    order to allow verifying every SingleResponse, 

                    it is important to include the relevant certificates
                    which are pertinent to every SingleResponse.

                
 

                
Proposed

                    full text replacement:

                
 

                
   The responder
                    MAY include certificates in the certs field of 

                
   BasicOCSPResponse

                    that help the OCSP client verify the responder's 

                
   signature.

                
 

                
   For every
                      SingleResponse where the responder is not a CA,
                      the 

                
   responder
                      SHALL include the relevant OCSP certificate in the
                      certs 

                
   field of
                      BasicOCSPResponse in order to allow the OCSP
                      client 

                
   verifying
                      the responder was entitled to include that
                      SingleResponse 

                
   in the
                      signed BasicOCSPResponse.

                
 

                
   If
                    no certificates are included then certs SHOULD be
                    absent.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
This requirement would break backwards compatibility with RFC
        2560.

      
Further this would not be needed for a locally configured
        responder.

      


      

      
        

          

            

                
 

                
19. Page
                    15. The ASN.1 syntax should be changed in order to
                    be able to use the enumeration case 7 that is not
                    used for CRLs. 

                    This leads to the following change:

                
 

                
Current
                    text:

                
 

                
       revocationReason    [0]     EXPLICIT
                      CRLReason OPTIONAL }

                
 

                
Proposed

                    text change:

                
 

                
Current
                    text:

                
 

                
       revocationReason
                         [0]     EXPLICIT
                      RevocationReason OPTIONAL }

                
 

                
RevocationReason
::=

                      ENUMERATED {

                
        unspecified                    (0),

                
        keyCompromise                  (1),

                
        cACompromise                   (2),

                
        affiliationChanged             (3),

                
        superseded                     (4),

                
        cessationOfOperation           (5),

                
        certificateHold                (6),

                
        notIssuedOrIrregularlyIssued

                        (7),

                
        removeFromCRL                  (8),

                
        privilegeWithdrawn             (9),

                
        aACompromise                  (10) }

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
You have to convince the list about your new reason code.

      


      

      
        

          

            

                
 

                
20.
                    Page 15. After the ASN.1 syntax, there is no
                    description of every parameter, neither on its use 

                    (except a few words in section 4.2.2.1 Time
                    about thisUpdate,
                      nextUpdate and producedAt).

                
 

                
Every
                    parameter needs to be described and explained.

                
 

                
   responderID
                      indicates either the name or the key from a CA, or
                      the 

                
   name or the
                      key from a OCSP Responder.

                
 

                
   producedAt
                      indicates the time at which this response was
                      signed.

                
 

                
   responses
                      contains one or more single responses.

                
 

                
   responseExtensions
                      is OPTIONAL.  Any

                      specific extension is OPTIONAL.

                
   The critical
                      flag may or may not be set.

                
 

                
   certID is
                      usually a copy of the same field which was placed
                      in the 

                
   request, but
                      for OCSP responders which pre-produce signed
                      responses 

                
   certID may
                      be the identifier of a target certificate that was
                      not 

                
   present in
                      the request (see the end of section 4.2).

                
 

                
   certStatus
                      indicates the status of the certificate: either
                      good, 

                
   revoked or
                      unknown.

                
 

                
   thisUpdate
                      indicates the time at which the status being
                      indicated 

                
   is known to
                      be correct.

                
 

                
   nextUpdate
                      indicates the time at or before which newer
                      information 

                
   will be
                      available about the status of the certificate.  If 

                
   nextUpdate
                      is not set, the server is indicating that newer 

                
   revocation
                      information is available all the time. 

                
 

                
   If
                      nextUpdate is set, it often corresponds to the
                      {thisUpdate, 

                
   nextUpdate}
                      interval in CRLs. 
                      Responses whose nextUpdate value is 

                
   earlier than
                      the local UTC time value SHOULD be considered 

                
   unreliable.  Responses
                      whose thisUpdate time is later than the local 

                
   UTC time
                      SHOULD be considered unreliable.

                
 

                
   singleExtensions
                      is OPTIONAL.  Any

                      specific extension is OPTIONAL.

                
   The critical
                      flag SHOULD NOT be set for any of them.

                
 

                
   revocationTime

                      indicates the time at which the certificate was 

                
   revoked.

                
 

                
   revocationReason
                      is OPTIONAL.  It

                      includes all the cases that are 

                
   present in
                      CRLReason used for CRLs and an additional case 7
                      which is

                
   not used for
                      CRLs.  Case
                      7 is called notIssuedOrIrregularlyIssued. 

                
 

                
      -
                      "notIssued" corresponds to the case where the
                      certificate 

                
         serial
                      number that was sent was erroneous and has not yet
                      

                
         been
                      used by the CA at the time of the query,

                
 

                
      -
                      "irregularlyIssued" corresponds to the case where
                      the 

                
         certificate

                      serial number that was sent really exists in a 

                
         certificate
                      that is correctly signed, but to its knowledge 

                
         the CA
                      has not issued a certificate with such a serial 

                
         number.
                       As an
                      example, it may have been issued by the CA 

                
         because
                      the RA was compromised. 

                
 

                
   When a responder responds revoked to a status request for which it 

                
   knows that the serial number has not been used by the CA or has 

                
   been irregularly used irregularly to issue a certificate, then 

                
   in RevokedInfo the responder MUST:

                
 

                
      - specify the revocationTime :  January 1, 1970,

                
      - provide the revocationReason: notIssuedOrIrregularlyIssued (7).

                
 

                
   and in SingleResponse the responder MUST NOT include the nextUpdate.

                
 

                
   The response
                      MUST include a SingleResponse for each certificate
                      in

                
   the request
                      and SHOULD NOT include any additional
                      SingleResponse

                
   elements.  However,
                      there is one exception: 

                
 

                
      OCSP
                      responders MAY pre-produce signed responses
                      specifying the 

                
      status of
                      certificates at a specified time.  The time at
                      which 

                
      the
                      status was known to be correct SHALL be reflected
                      in the 

                
      thisUpdate
                      field of the response. 

                
 

                
      OCSP
                      responders that pre-generate status responses MAY
                      return 

                
      responses
                      that include additional SingleResponse elements if

                
      necessary
                      to improve response pre-generation performance or
                      cache

                
      efficiency
                      (as permitted in [RFC5019]).

                
 

                
Since
                    the text above provides all the explanations at the
                    level of the ASN.1 parameters, the general text 

                    from section
                      4.2.2.3 Basic Response is
                    no more need and should be deleted.

                
 

              

          

        

      
      


      

      
Preliminary I would say "not broken".

      
If you don't replace 4.2.2.3, then what really are you
        missing?

      


      

      
        

          

            

                
 

                
21. 0n
                    page 16, there is a section 4.2.2.2 called “Authorized Responders”

                
 

                
Section
                    4.2.2.2 states:

                
 

                
   (…)

                
   This
                      certificate MUST be issued directly by the CA that
                      issued the

                
   certificate
                      in question.

                
 

                
   The CA
                      SHOULD use the same issuing key to issue a
                      delegation

                
   certificate
                      as was used to sign the certificate being checked
                      for

                
   revocation.
                      Systems relying on OCSP responses MUST recognize a

                
   delegation
                      certificate as being issued by the CA that issued
                      the

                
   certificate
                      in question only if the delegation certificate and
                      the

                
   certificate
                      being checked for revocation was signed by the
                      same key.

                
 

                
This
                    section would need to reformatted to address CA
                    requirements first and then OCSP responder
                    requirements:

                
 

                
   (…)

                
   This
                      certificate MUST be issued directly by the CA that
                      issued the

                
   certificate
                      in question.  The
                      CA SHOULD use the same issuing key to 

                
   issue a
                      delegation certificate as was used to sign the
                      certificate 

                
   being
                      checked for revocation. 

                
 

                
   Systems
                      relying on OCSP responses MUST be able to
                      recognize a 

                
   delegation
                      certificate as being issued by the CA that issued
                      the 

                
   certificate
                      in question if the delegation certificate and 

                
   the
                      certificate being checked were signed by
                      the same key.

                
 

              

          

        

      
      


      

      
I disagree. The CA is actually free to do anything, but
        cannot expect the client to recognise the responder as
        authorised unless the same private key is used.

      
The current text places the requirement where they belong.

      


      

      
        

          

            

                
 

                
22. On
                    page 17, the text states:

                
 

                
   They MUST
                      reject the

                
   response if
                      the certificate required to validate the signature
                      on the

                
   response
                      fails to meet at least one of the following
                      criteria:

                
 

                
This
                    is ambiguous. It is inappropriate to have a negative
                    statement like “They MUST
                      reject”. 

                    The sentence should be turned in the positive form “They
                      SHALL accept” 

                
 

                
Since
                    the ASN.1 syntax has now be described, it is
                    possible to be more specific.

                
 

                
The
                    first occurrence of the word “response” should be
                    changed into “singleResponse”, while the second
                    occurrence 

                    of the word “response” should be changed into
                    “ResponseData”

                
 

                
Proposed

                    text replacement:

                
 

                
   They SHALL
                      accept a singleResponse if the certificate
                      required to 

                
   validate the
                      signature placed on the ResponseData meets one of
                      the 

                
   following
                      criteria:

              

          

        

      
      


      

      


      

      
No, this change is not backwards compatible.

      
So state the requirements for rejection is not equivalent to
        stating requirements for acceptance.

      
There may be other locally configured reasons to reject in
        addition to those listed in the standard.

      


      

      


      

      
        

          

            

                
 

                
 

                
23. On
                    page 17, the text states:

                
 

                
   3. Includes
                      a value of id-kp-OCSPSigning in an
                      ExtendedKeyUsage

                
   extension
                      and is issued by the CA that issued the
                      certificate in

                
   question as
                      stated above."

                
 

                
In
                    order to be crystal clear, it is proposed to change
                    the wording in the following way:

                
 

                
   3. Includes
                      a value of id-kp-OCSPSigning in an
                      ExtendedKeyUsage

                
   extension
                      and was signed by the CA using the same key that
                      used 

                
   to issue the
                      certificate in question.

                
 

              

          

        

      
      


      

      
No, issuing with another key is not prohibited, and may be
        accepted by some clients as an authorised responder.

      


      

      
        

          

            

                
 

                
24. On
                    page 17, the text states:

                
 

                
   This SHOULD
                      be a non-critical extension. The value of the
                      extension 

                
   SHALL be
                      NULL.

                
 

                
The
                    ASN.1 syntax is missing. Add: 

                
 

                
   NoCheck ::=
                      NULL

                
 

                
 

              

          

        

      
      


      

      
Moving this to a separate discussion.

      
I'm not sure what the preferred way to describe this is.

      


      

      


      

      
        

          

            

                
25.
                    Remainder: On page 18, the general text from section 4.2.2.3 Basic Response is no
                    more needed and 

                    should be deleted. See comment 20.

                
 

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
26. On
                    page 24, text should be added to the Security
                    consideration section:

                
 

                
Different

                      results when using OCSP and CRLs

                
 

                
   OCSP clients
                      or verifiers must build and verify a certification
                      path 

                
   for each
                      target certificate up to a trusted root.  When an OCSP
                      

                
   Responder is
                      using published CRLs, it must also build and
                      verify a 

                
   certification
                      path for the CRLs it uses up to a trusted root.

                
 

                
   However, it
                      should be realized that the root used by an OCSP 

                
   Responder to
                      verified these CRLs is not necessarily the same as
                      the 

                
   one that
                      would be used by the OCSP client, if it were going
                      to verify 

                
   the CRLs
                      itself.  Hence
                      the revocation status may not be identical 

                
   in both
                      cases.

                
 

                
 

              

          

        

      
      


      

      
I don't understand this one.

      


      

      
        

          

            

                
27. On
                    page 24, text should be added to the Security
                    consideration section:

                
 

                
Denial

                      of service attack using a flood of queries

                
 

                
   A denial of
                      service vulnerability is evident with respect to a
                      flood 

                
   of queries.  The
                      production of a cryptographic signature 

                
   significantly
                      affects response generation cycle time, thereby 

                
   exacerbating
                      the situation. 

                
 

                
   The flood of
                      queries may either come from a flood attack or
                      from the 

                
   fact that
                      there are too many certificates supported by the
                      same OCSP 

                
   responder.  In the later
                      case, the number of queries can be 

                
   reduced by
                      using a technique similar to the splitting of
                      CRLs: 

                
 

                
      When a
                      block of certificates have been issued with the
                      same 

                
      accessLocation
                      in the AIA extension field of these certificates,
                      

                
      then the
                      accessLocation should be changed.  In this way,
                      a given 

                
      OCSP
                      server will only be responsible for a block of
                      certificates.

                
 

              

          

        

      
      


      

      
If the security considerations section is talking about
        splitting OCSP responders in this way, then the document itself
        need to introduce the subject.

      
I would suggest that it is beyond this update to do so.

      


      

      
        

          

            

                
 

                
28. On
                    page 31, the text states.

                
 

                
   An
                      alternative to this module that conforms to the
                      2002 version of 

                
   ASN.1 may be
                      found in Section 4 of [RFC5912]. 

                
 

                
RFC
                    5912 omits to define the nocheck extension. Thus it
                    is inappropriate to refer to RFC 5912. 

                
 

                
The
                    corrected module should be defined in this new
                    draft. 

                    A corrected module is provided in draft-pinkas-rfc2560bis-03.

                
 

              

          

        

      
      


      

      
Will move this (as stated above) to a separate discussion.

      


      

      
        

          

            

                
 

                
29.
                    Different topics are not covered by the document.
                    These topics are important. 

                    The following comments propose text to be placed in
                    annexes. Three annexes are being proposed.

                
 

                
Note:
                    The texts are extracted from draft-pinkas-rfc2560bis-03.

                
 

                
 

              

          

        

      
      


      

      
Not broken.

      
Each such amendment need to be thoroughly reviewed and
        motivated.

      


      

      


      

      
        

          

            

                
30. First
                    annex being proposed. This annex is important,
                    because key rollover is not addressed in the draft.

                
 

                
KEY

                      ROLLOVER

                
 

                
1.
                      CA that directly supports an OCSP service

                
 

                
   When a CA
                      that directly supports an OCSP service performs a
                      key 

                
   rollover:

                
 

                
   - for
                      certificates issued under the old key, the CA
                      SHALL continue 

                
     to sign
                      the revocation status of OCSP responses with that
                      old key 

                
     at least
                      until all these certificates are expired, and

                
 

                
   - for
                      certificates issued under the new key, the CA
                      SHALL change the 

                
     accessLocation
                      in the AIA extension field of these certificates 

                
     and sign
                      the revocation status of OCSP responses with that
                      new key 

                
     at least
                      until all these certificates are expired.

                
 

                
   Note: The
                      change in accessLocation is necessary when the CA
                      rekeys 

                
         to
                      meet the following constraints imposed by this
                      standard: 

                
 

                
            1)
                      a BasicOCSPResponse can only be signed using a
                      single 

                
               private

                      key; 

                
 

                
            2)
                      the response must be signed using the same CA key
                      that 

                
               was used to
                      sign the certificate in question; and

                
 

                
            3)
                      the OCSP response needs to cover all the
                      certificates 

                
               queried
                      in the OCSP request.

                
 

                
2.
                      CA that uses OCSP responders

                
 

                
   When a CA
                      that uses OCSP Responders performs a key rollover,
                      then 

                
   it MUST
                      either designate a new OCSP Responder or keep the
                      current 

                
   OCSP
                      Responder(s).

                
 

                
   If the CA
                      designates a new OCSP Responder, then it SHALL
                      change the 

                
   accessLocation
                      in the AIA extension field for the newly issued 

                
   certificates
                      and issue an OCSP certificate to the new OCSP
                      Responder 

                
   using its
                      new key.

                
 

                
   If the CA
                      keeps the same OCSP Responder(s), then it SHALL
                      continue 

                
   to use the
                      same accessLocation(s) in the AIA extension field
                      for the 

                
   newly issued
                      certificates and issue an OCSP certificate to the
                      

                
   appropriate
                      OCSP Responder(s) using its new key.

                
 

                
   Note: The CA
                      may need to continue issuing certificates to the
                      OCSP 

                
   Responder(s)
                      using the old CA key until all the certificates
                      issued 

                
   under the
                      CA' old key for which the OCSP Responder(s) are 

                
   authoritative
                      have expired.

                
 

                
3.
                      OCSP Responder key rollover

                
 

                
   When an OCSP
                      Responder performs a key rollover (asynchronously
                      from 

                
   a CA key
                      rollover), then each CA which has designated an
                      OCSP 

                
   Responder
                      SHALL issue a new certificate for that OCSP
                      Responder and 

                
   for each of
                      its issuing keys which meets the following
                      property: 

                
 

                
      - the
                      issuing key has been used to sign at least one
                      certificate 

                
        which
                      contains an AIA extension designating that OCSP
                      Responder 

                
        and
                      that certificate is not yet expired.

                
 

                
   An OCSP
                      Responder key rollover does not affect the values
                      of the 

                
   URIs that
                      are placed in the accessLocation field from the
                      target 

                
   certificates.  One or more
                      OCSP Responder MAY respond to an OCSP 

                
   request
                      addressed at a given URI picked from the
                      accessLocation 

                
   field from a
                      target certificate. 
                      Each OCSP Responder MAY use a 

                
   different
                      signing key, as long as it got an OCSP certificate
                      

                
   appropriate
                      for that signing key and for the target
                      certificate. 

                
 

                
 

                
31. Second
                    annex being proposed. This annex is important
                    because it describes the validation of an OCSP
                    response in the past 

                    which is of a particular importance when validating
                    electronic signatures.

                
 

                
Response

                      processing by an OCSP client

                
 

                
   OCSP
                      responses can be verified at the current time by
                      an OCSP client 

                
   when
                      receiving a response, whereas old responses can be
                      verified at 

                
   a time in
                      the past by a verifier.  The algorithm
                      below addresses 

                
   both cases.

                
 

                
   Prior to
                      processing a basic response, OCSP clients MUST
                      determine 

                
   the checking
                      time, which may be either the current time or a
                      time 

                
   in the past.

                
 

                
   OCSP clients
                      or verifiers SHALL check if the response contains
                      

                
   responseExtensions.
                      If such an extension is found and is recognized, 

                
   it MUST be
                      processed.  If
                      such a critical extension is found and 

                
   is not
                      recognized, the whole OCSP response MUST be
                      considered as 

                
   invalid.

                
 

                
   If the
                      checking time is the current time, and if a nonce
                      extension 

                
   has been
                      used in the request and is recognized (see section
                      4.5.1), 

                
   OCSP clients
                      MUST check whether the same nonce is present in
                      the 

                
   response.  If the nonce
                      is not present or is different, then the 

                
   OCSP
                      response MUST be discarded.

                
 

                
   Only the
                      single response(s) which are/is of interest SHALL
                      be 

                
   checked.

                
 

                
STEP

                      1

                
 

                
   OCSP clients
                      or verifiers SHALL verify that the certificate 

                
   identified
                      in a single response is of interest.  Otherwise,
                      proceed 

                
   to step 3.

                
 

                
   If the
                      certificate status included in a single
                      certificate response 

                
   is
                      "unknown", then the revocation status of that
                      certificate is 

                
   "unknown",
                      and proceed to step 3.

                
 

                
   If the
                      certificate status from the single certificate
                      response is 

                
   either
                      "good" or "revoked", OCSP clients or verifiers
                      SHALL check 

                
   that the
                      checking time is within the validity period of the
                      target 

                
   certificate.  If it is not
                      the case, then the revocation status of 

                
   that
                      certificate is "unknown" and proceed to step 3.

                
 

                
   If the
                      checking time is the current time, and if a nonce
                      has been 

                
   used in the
                      request, then proceed to step 2.

                
 

                
   If the
                      checking time is the current time, and if no nonce
                      has been 

                
   used in the
                      request, OCSP clients MUST check that the
                      producedAt

                
   field is
                      within a time window that is "close enough" to the
                      current 

                
   time. 

                
 

                
   Note: the
                      notion of "close enough" is a local matter.  It can be set
                      

                
         to a
                      few minutes to allow for small UTC time
                      differences 

                
         between
                      the client and the server or to a few hours in
                      case 

                
         the
                      server is producing pre-computed responses.

                
 

                
   If the
                      checking time is a time in the past, verifiers
                      MUST check 

                
   that the
                      producedAt field is in accordance with the
                      verification 

                
   rules (e.g.
                      close and/or after the date of a time-stamp
                      token).

                
 

                
   In addition,
                      if the nextUpdate field is present, OCSP clients
                      MUST 

                
   check that
                      the time which is indicated is greater than the
                      checking 

                
   time,
                      otherwise the single response MUST be discarded.

                
 

                
   If checks
                      are successful, then OCSP clients MUST process the
                      

                
   singleExtensions

                      field, if it is present. 

                
 

                
   If the
                      criticality flag is set and the extension is not
                      understood, 

                
   then the
                      status of the certificate shall be "unknown" and
                      proceed to 

                
   step 3.  Otherwise,
                      proceed to step 2. 

                
 

                
   If the
                      extension is understood, then the extension MUST
                      be 

                
   processed.  According to
                      its content proceed either to step 2 or to 

                
   step 3. 

                
 

                
STEP

                      2

                
 

                
   OCSP clients
                      or verifiers MUST build and verify a certification
                      path 

                
   for that
                      certificate up to a trusted root, so that they
                      have the 

                
   knowledge of
                      the CA public key value that was used to sign the
                      

                
   target
                      certificate.  The
                      revocation status of each certificate of 

                
   that
                      certification path (except the target certificate)
                      SHALL be 

                
   checked.

                
 

                
   If no path
                      can be built or if one of the certificates of the
                      path is 

                
   revoked,
                      then the revocation status of that certificate is
                      "unknown", 

                
   and proceed
                      to step 3. 

                
 

                
   If the
                      certification path (except the target certificate)
                      is valid, 

                
   then two
                      cases need to be considered:

                
 

                
   a) If the
                      responderID matches with the name or the key from
                      the CA 

                
      which has
                      issued the target certificate, then check whether
                      the 

                
      OCSP
                      response is signed by the same key that was used
                      to sign 

                
      the
                      target certificate.

                
 

                
             If
                      it is the case, then the revocation status of that
                      

                
             certificate

                      as indicated in the certStatus field is 

                
             accepted
                      and proceed to step 3.

                
 

                
             If
                      it is not the case, then the revocation status of
                      that 

                
             certificate

                      is "unknown" and proceed to step 3.

                
 

                
   b) If the
                      responderID does not match with the name or the
                      key from 

                
      the CA
                      which has issued the target certificate, then it
                      indicates 

                
      the name
                      or the key from an OCSP Responder.  Check whether
                      there 

                
      exists a
                      local rule which applies to this target
                      certificate to 

                
      verify
                      that the signature of the BasicOCSPResponse is
                      valid for 

                
      that
                      single response.  If
                      this rule exists, it SHALL be followed. 

                
 

                
      Otherwise
                      check whether there is an OCSP certificate (i.e.
                      which 

                
      has both
                      the ocspSigning OID in the extended key usage
                      extension 

                
      and the
                      digitalSignature bit in the key usage extension)
                      signed 

                
      by the
                      same key that was used to sign the target
                      certificate. 

                
      This
                      certificate MUST be present in the certs field
                      from the 

                
      BasicOCSPResponse.

                      

                
 

                
          If
                      such certificate is not found or is invalid, then
                      the 

                
          revocation

                      status of that certificate is "unknown" and 

                
          proceed
                      to step 3.

                
 

                
          If
                      such certificate exists and if the checking time
                      is 

                
          within
                      the validity period of this certificate, then it
                      MUST 

                
          be
                      verified whether the OCSP response can be verified
                      using 

                
          the
                      public key that is present in the OCSP
                      Certificate. 

                
 

                
             If
                      it is not the case, then the revocation status of
                      that 

                
             certificate

                      is "unknown" and proceed to step 3.

                
 

                
             If
                      it is the case, then it MUST be verified that the
                      OCSP 

                
             Certificate

                      has not been revoked.

                
 

                
     If one of
                      these conditions is met, then the status for the
                      target 

                
     certificate
                      as indicated in the certStatus field is accepted,
                      

                
     otherwise
                      the revocation status is "unknown".

                
 

                
STEP

                      3

                
 

                
   If there
                      exists another single certificate status response
                      for a 

                
   target
                      certificate that is of interest, then proceed to
                      step 1. 

                
   Otherwise
                      the basic response is now processed.

                
 

                
 

                
32. Third
                    annex being proposed. This annex is important
                    because it provides guidance on how to build an OCSP
                    responder in the three cases. 

                    Many text portions are similar, but three full texts
                    are provided in order to provide a better clarity
                    for each of the three cases.

                
 

                
1.
                      Request processing by OCSP servers

                
 

                
   The behavior
                      of an OCSP server will be different whether the
                      OCSP 

                
   server is a
                      CA acting as an OCSP responder, is an OCSP
                      Responder 

                
   which
                      received a delegation from one or more CAs, or is
                      a locally 

                
   trusted
                      Responder.

                
 

                
1.1.

                      Processing by a CA acting as an OCSP responder

                
 

                
   The OCSP
                      responder SHALL maintain a list of entries. Each
                      entry 

                
   SHALL
                      contain:

                
 

                
     - the URI
                      associated to the OCSP responder, from which the
                      OCSP 

                
       requests
                      are received, 

                
 

                
     - the DN
                      from a CA,

                
 

                
     - an
                      issuing public key from a CA,

                
 

                
     - the
                      method(s) used to know for which subset of
                      certificates 

                
       issued
                      by the CA it is responsible for, 

                
 

                
     - the
                      method(s) used to obtain the revocation status of
                      that 

                
       subset
                      of certificates issued under that CA issuing
                      public key, 

                
       and

                
 

                
     - the
                      method used to gain access and sign with the
                      private key 

                
       corresponding
                      to the issuing public key.

                
 

                
   For a given
                      URI value, the OCSP responder SHALL only use one
                      CA 

                
   key pair
                      value. 

                
 

                
   When it
                      receives an OCSP request on that URI, the OCSP
                      responder 

                
   SHALL handle
                      exceptions according to section 2.3. 

                
 

                
   If the OCSP
                      request contains the name of a requestor, the OCSP
                      

                
   responder
                      SHALL verify whether there exists a locally
                      defined rule 

                
   which
                      regulates access control.  If this rule
                      exists, it SHALL be 

                
   followed.

                
 

                
   Then, for
                      each target certificate, the OCSP responder SHALL
                      verify 

                
   whether both
                      the hash of the issuer's DN and the hash of the
                      issuer 

                
   public key
                      which are present in the request are eligible to a
                      

                
   locally
                      defined rule which indicates that the OCSP
                      responder is 

                
   responsible
                      to provide the revocation status of that target 

                
   certificate.  If this rule
                      exists, it SHALL be followed.

                
 

                
   Otherwise,
                      the OCSP responder SHALL determine whether it is 

                
   responsible
                      to provide the revocation status of that target 

                
   certificate
                      according to the following rule.

                
 

                
   For each
                      target certificate, the OCSP responder SHALL
                      verify whether 

                
   both the
                      hash of the issuer's DN and the hash of the issuer
                      public 

                
   key which
                      are present in the request match respectively with
                      the DN 

                
   and the hash
                      of the public key of contained in an entry from
                      the 

                
   list of
                      entries maintained by this OCSP responder. 

                
 

                
   When there
                      is no match, then the OCSP responder SHALL
                      indicate the 

                
   "unknown"
                      status and proceed with the next target
                      certificate from 

                
   the OCSP
                      request.

                
 

                
   When there
                      is a match, then the OCSP responder SHALL use the
                      serial 

                
   number of
                      the target certificate that is present in the
                      request and 

                
   determine
                      the revocation status of that certificate
                      according to 

                
   the
                      method(s) defined in the entry. 

                
 

                
   When the
                      revocation status is provided by the server using
                      a real 

                
   time access
                      to a database of revocation statuses of issued 

                
   certificates,
                      then the thisUpdate field SHALL be present in the

                
   SingleResponse

                      response whereas the nextUpdate field SHALL be 

                
   missing. 

                
 

                
   Otherwise,
                      both the thisUpdate and the nextUpdate fields
                      SHALL be 

                
   present in
                      the SingleResponse. 

                
 

                
   The time at
                      which this response will be signed MUST be
                      indicated in 

                
   the
                      producedAt field from the SingleResponse.

                
 

                
   If a
                      singleRequestExtensions is present in the request
                      it MUST be 

                
   processed.

                
 

                
   If there is
                      another target certificate present in the request,
                      it 

                
   SHALL be
                      processed in the same way.

                
 

                
   If a
                      requestExtensions is present in the request it
                      MUST be 

                
   processed.

                
 

                
   The OCSP
                      response MUST be signed using the CA issuing
                      private key.

                
 

                
 

                
1.2.

                      Processing by an OCSP Responder

                
 

                
   For each CA
                      from which the OCSP Responder has received a
                      delegation, 

                
   the OCSP
                      Responder SHALL maintain a list of entries. 

                
 

                
   Each entry
                      SHALL contain:

                
 

                
     - the URI
                      associated to this OCSP Responder, from which the
                      OCSP 

                
       requests
                      are received, 

                
 

                
     - the DN
                      from a CA,

                
 

                
     - an
                      issuing public key from a CA,

                
 

                
     - the
                      method(s) used to know for which subset of
                      certificates 

                
       issued
                      by the CA it is responsible for, 

                
 

                
     - the
                      method(s) used to obtain the revocation status of
                      that 

                
       subset
                      of certificates issued under that CA issuing
                      public key,

                
 

                
     - an OCSP
                      certificate, 

                
 

                
     - the OCSP
                      public key contained in that OCSP certificate, and

                
 

                
     - the
                      method used to gain access and sign with the OCSP
                      private 

                
       key
                      corresponding to that OCSP certificate.

                
 

                
   For a given
                      URI value, the OCSP Responder SHALL only use one
                      OCSP 

                
   key pair
                      value.  Therefore
                      there cannot be two entries with the 

                
   same URI
                      value and a different OCSP public key value.

                
 

                
   NOTE: a
                      BasicOCSPResponse can only be signed using a
                      single private 

                
         key. 

                
 

                
   The OCSP
                      certificate SHALL be signed by the CA issuing
                      private key 

                
   which
                      corresponds to the issuing CA public key that is
                      in this 

                
   entry.

                
 

                
   When it
                      receives an OCSP request, the OCSP responder SHALL
                      handle 

                
   exceptions
                      according to section 2.3. 

                
 

                
   If the OCSP
                      request contains the name of a requestor, the OCSP
                      

                
   responder
                      SHALL verify whether there exists a locally
                      defined rule 

                
   which
                      regulates access control.  If this rule
                      exists, it SHALL be 

                
   followed.

                
 

                
   For each
                      target certificate, the OCSP Responder SHALL
                      verify 

                
   whether both
                      the hash of the issuer's DN and the hash of the
                      issuer 

                
   public key
                      which are present in the OCSP request match with
                      those 

                
   from an
                      entry.

                
 

                
   When there
                      is no match, then the OCSP Responder SHALL
                      indicate the 

                
   "unknown"
                      status and proceed with the next target
                      certificate from 

                
   the OCSP
                      request.

                
 

                
   When there
                      is a match, the OCSP Responder SHALL use the
                      serial 

                
   number of
                      the target certificate this is present in the OCSP
                      

                
   request to
                      determine the revocation status of that
                      certificate 

                
   according to
                      the method(s) indicated in the entry. 

                
 

                
   When the
                      revocation status is provided by the server using
                      a real 

                
   time access
                      to a database of revocation statuses of issued 

                
   certificates,
                      then the thisUpdate field SHALL be present in the

                
   SingleResponse

                      response whereas the nextUpdate field SHALL be 

                
   missing. 

                
 

                
   Otherwise,
                      both the thisUpdate and the nextUpdate fields
                      SHALL be 

                
   present in
                      the SingleResponse. 

                
 

                
   The time at
                      which this response will be signed MUST be
                      indicated in 

                
   the
                      producedAt field from the SingleResponse.

                
 

                
   If a
                      singleRequestExtensions is present in the request
                      it MUST be 

                
   processed.

                
 

                
   If there is
                      another target certificate present in the request,
                      it 

                
   SHALL be
                      processed in the same way.

                
 

                
   If a
                      requestExtensions is present in the request it
                      SHALL be 

                
   processed.

                
 

                
   The OCSP
                      response MUST be signed using the OCSP private
                      key.

                
 

                
   Unless there
                      is a local rule which states differently, for
                      every 

                
   target
                      certificate which matches both with the hash of a
                      CA DN and an 

                
   issuing
                      public key from an entry, the OCSP certificate of
                      that entry 

                
   SHALL be
                      placed in the certs field.

                
 

                
   It may
                      happen, that none of the target certificates from
                      the OCSP

                
   request
                      matches both with the hash of a CA DN and an
                      issuing public 

                
   key from an
                      entry.  In
                      that case and unless a local rule states 

                
   differently,
                      the certs field from the BasicOCSPResponse SHOULD
                      be 

                
   kept empty
                      (to limit the disclose of the names of the CAs
                      from which 

                
   the OCSP
                      Responder received a delegation from).

                
 

                
1.3.

                      Processing by a locally trusted Responder

                
 

                
   For each CA
                      for which the locally trusted Responder is 

                
   authoritative,
                      the OCSP Responder SHALL maintain a list of
                      entries. 

                
 

                
   Each entry
                      SHALL contain:

                
 

                
     - the URI
                      associated to this OCSP Responder, from which the
                      OCSP 

                
       requests
                      are received, 

                
 

                
     - the DN
                      from a CA,

                
 

                
     - an
                      issuing public key from a CA,

                
 

                
     - the
                      method(s) used to know for which subset of
                      certificates 

                
       issued
                      by the CA it is responsible for, 

                
 

                
     - the
                      method(s) used to obtain the revocation status of
                      that 

                
       subset
                      of certificates issued under that CA issuing
                      public key,

                
 

                
     - the
                      method used to gain access to the private key in
                      order to 

                
       sign the
                      OCSP response. 

                
 

                
   For a given
                      URI value, the OCSP Responder SHALL only use one
                      private 

                
   key.  Therefore
                      there cannot be two entries with the same URI
                      value 

                
   and a
                      different method to gain access to the appropriate
                      private key.

                
 

                
   NOTE: a
                      BasicOCSPResponse can only be signed using a
                      single private 

                
         key. 

                
 

                
   When it
                      receives an OCSP request, the OCSP responder SHALL
                      handle 

                
   exceptions
                      according to section 2.3. 

                
 

                
   If the OCSP
                      request contains the name of a requestor, the OCSP
                      

                
   responder
                      SHALL verify whether there exists a locally
                      defined rule 

                
   which
                      regulates access control.  If this rule
                      exists, it SHALL be 

                
   followed.

                
 

                
   For each
                      target certificate, the OCSP Responder SHALL
                      verify 

                
   whether both
                      the hash of the issuer's DN and the hash of the
                      issuer 

                
   public key
                      which are present in the OCSP request match with
                      those 

                
   from an
                      entry.

                
 

                
   When there
                      is no match, then the OCSP Responder SHALL
                      indicate the 

                
   "unknown"
                      status and proceed with the next target
                      certificate from 

                
   the OCSP
                      request.

                
 

                
   When there
                      is a match, the OCSP Responder SHALL use the
                      serial 

                
   number of
                      the target certificate this is present in the OCSP
                      

                
   request to
                      determine the revocation status of that
                      certificate 

                
   according to
                      the method(s) indicated in the entry. 

                
 

                
   When the
                      revocation status is provided by the server using
                      a real 

                
   time access
                      to a database of revocation statuses of issued 

                
   certificates,
                      then the thisUpdate field SHALL be present in the

                
   SingleResponse

                      response whereas the nextUpdate field SHALL be 

                
   missing. 

                
 

                
   Otherwise,
                      both the thisUpdate and the nextUpdate fields
                      SHALL be 

                
   present in
                      the SingleResponse. 

                
 

                
   The time at
                      which this response will be signed MUST be
                      indicated in 

                
   the
                      producedAt field from the SingleResponse.

                
 

                
   If a
                      singleRequestExtensions is present in the request
                      it MUST be 

                
   processed.

                
 

                
   If there is
                      another target certificate present in the request,
                      it 

                
   SHALL be
                      processed in the same way.

                
 

                
   If a
                      requestExtensions is present in the request it
                      SHALL be 

                
   processed.

                
 

                
   The OCSP
                      response MUST be signed using the OCSP private
                      key.

                
 

                
   The certs
                      field may contain no, one or several OCSP
                      certificates 

                
   according to
                      local rules followed by the locally trusted
                      Responder.

              

          

        

      
      


      

      
Not broken.

      


      

      
/Stefan

      


      

      
        

          

            

                
 

                
 

                
End of
                    comments

                  

                


                  Denis

                  

                
 

               

          

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

      
    

    

  


--------------030806070903090303090301--


From internet-drafts@ietf.org  Mon Feb 11 15:11:52 2013
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 9F48721F8826; Mon, 11 Feb 2013 15:11:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.557
X-Spam-Level: 
X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 mpuwOrg+IoZ5; Mon, 11 Feb 2013 15:11:52 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F2221F8887; Mon, 11 Feb 2013 15:11:51 -0800 (PST)
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.37
Message-ID: <20130211231151.13794.3100.idtracker@ietfa.amsl.com>
Date: Mon, 11 Feb 2013 15:11:51 -0800
Cc: pkix@ietf.org
Subject: [pkix] I-D Action: draft-ietf-pkix-est-04.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: Mon, 11 Feb 2013 23:11:52 -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           : Enrollment over Secure Transport
	Author(s)       : Max Pritikin
                          Peter E. Yee
                          Dan Harkins
	Filename        : draft-ietf-pkix-est-04.txt
	Pages           : 51
	Date            : 2013-02-11

Abstract:
   This document profiles certificate enrollment for clients using
   Certificate Management over CMS (CMC) messages over a secure
   transport.  This profile, called Enrollment over Secure Transport
   (EST), describes a simple yet functional certificate management
   protocol targeting Public Key Infrastructure (PKI) clients that need
   to acquire client certificates and associated Certification Authority
   (CA) certificate(s).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pkix-est

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pkix-est-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-est-04


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


From stefan@aaa-sec.com  Tue Feb 12 04:15:24 2013
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 A64B021F8D4C for ; Tue, 12 Feb 2013 04:15:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.934
X-Spam-Level: 
X-Spam-Status: No, score=-101.934 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 7J7GNG2++H+e for ; Tue, 12 Feb 2013 04:15:21 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 2F66A21F8D49 for ; Tue, 12 Feb 2013 04:15:16 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 43FB73AA83E for ; Tue, 12 Feb 2013 13:15:15 +0100 (CET)
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 MWtdbFioNWp6 for ; Tue, 12 Feb 2013 13:15:15 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 004043AA818 for ; Tue, 12 Feb 2013 13:15:15 +0100 (CET)
Received: (qmail 51734 invoked from network); 12 Feb 2013 12:15:14 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.105]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 12 Feb 2013 12:15:14 -0000
User-Agent: Microsoft-MacOutlook/14.3.0.121105
Date: Tue, 12 Feb 2013 13:15:14 +0100
From: Stefan Santesson 
To: 
Message-ID: 
Thread-Topic: AuthContext Certificate extension 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: [pkix] AuthContext Certificate 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: Tue, 12 Feb 2013 12:15:24 -0000

I hav submitted a new draft as an individual submission:

http://www.ietf.org/id/draft-santesson-auth-context-extension-00.txt

Abstract

   This document defines an extension to certificates according to
   [RFC5280]. The extension defined in this document holds data about
   how the certificate subject was authenticated by the Certification
   Authority who issued the certificate where this extension appears.

   This document also defines one data structure for inclusion in this
   extension that designed to hold information when the subject is
   authenticated using a SAML assertion [SAML].




This draft documents an extension that we have defined in the Swedish
national electronic identification infrastructure in order to be able to
match SAML credentials with associated electronic signatures.
All signature certificates are issued by a central signature generation
service which authenticates the user using SAML credentials and then adds
this extension to the certificate.

This makes it possible for service providers to compare the signer of a
document with the entity currently logged into the service using SAML.

I would have loved for this to be part of the PKIX process, but as we are
not allowed to take on any further work, I let this do as an individual
submission.

Currently the draft is based on the Swedish defined OIDs.

There is still a short window before we need to lock this specification in
the Swedish project, but I'm very interested in review from members of
this group.
The intention is currently to go Informational, in order to just provide a
stable reference to this extension definition.
Should there be an interest in moving this to standards track, then I
would not object to doing so.

/Stefan




From hotz@jpl.nasa.gov  Tue Feb 12 21:49:59 2013
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 CAE4F21F8A69 for ; Tue, 12 Feb 2013 21:49:57 -0800 (PST)
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 3-qDPrmu7ve8 for ; Tue, 12 Feb 2013 21:49:56 -0800 (PST)
Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 124DE21F8A64 for ; Tue, 12 Feb 2013 21:49:52 -0800 (PST)
Received: from [192.168.2.150] (adsl-99-106-242-90.dsl.lsan03.sbcglobal.net [99.106.242.90]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r1D5nkp2018936 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 12 Feb 2013 21:49:47 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Henry B. Hotz" 
In-Reply-To: <043401cdedf8$f11749c0$d345dd40$@ditenity.com>
Date: Tue, 12 Feb 2013 21:49:45 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <64F1430F-1B31-4B42-A8CE-059B61EF215A@jpl.nasa.gov>
References: <50EC6F85.7020802@bbn.com> <195DB2510AAA004391F58E28FCE2120006700384@IMCMBX01.MITRE.ORG> <5B1D7E570380A64989D4C069F7D14BC85AC6AB66@clavin.missi.ncsc.mil> <043401cdedf8$f11749c0$d345dd40$@ditenity.com>
To: Piyush Jain 
X-Mailer: Apple Mail (2.1499)
X-Source-Sender: hotz@jpl.nasa.gov
X-JPL-Spam-Score': 80%
Cc: 'pkix' 
Subject: Re: [pkix] why revoked certificate entry has to be included in one CRL issued beyond certificate validity period
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, 13 Feb 2013 05:49:59 -0000

I understand the argument, but I think that pragmatically it's a =
distinction without a difference.  Maybe the RP should make the =
decision, but it needs information from the CA to base the decision on.  =
That being the case, who's really making the decision?

Also, and I've said this before, if the availability of PKI-protected =
services are really critical, then no RP would ever cease functioning =
just because someone was DOSing the source of CRLs.
------------------------------------------------------
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

On Jan 8, 2013, at 3:36 PM, Piyush Jain  wrote:

> The question is - who is in the best position to determine that grace =
period
> beyond CRL issuance time.
> I would think that it is up to the RP to determine its risk window.=20
>=20
> CA should not and cannot make that determination for a relying party.
>=20
> On the other hand, such a private extension would have given some =
comfort to
> those RPs who are reluctant to define their own risk tolerance.
>=20
>=20
>> -----Original Message-----
>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf =
Of
>> Kemp, David P.
>> Sent: Tuesday, January 08, 2013 1:34 PM
>> To: pkix
>> Subject: Re: [pkix] why revoked certificate entry has to be included =
in
> one
>> CRL issued beyond certificate validity period
>>=20
>> To be fair, the last time this came up a few years ago PKIX missed =
the
>> opportunity to define an Internet Private CRL Extension that would =
allow
> CAs
>> to suggest a grace period beyond which RPs should not consider the =
CRL
>> fresh.  If a standard useBy date were defined, consumers would have =
an
>> easier time jawboning RP software vendors to stop treating nextUpdate =
as
>> an expiration date.
>>=20
>> Dave
>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf =
Of
>> Miller, Timothy J.
>> Sent: Tuesday, January 08, 2013 2:23 PM
>> To: Stephen Kent
>> Cc: pkix
>> Subject: Re: [pkix] why revoked certificate entry has to be included =
in
> one
>> CRL issued beyond certificate validity period
>>=20
>> While I appreciate and would prefer the BOFH approach to deficiency
>> remediation, practically speaking you can't push a rope.  :)  Absent =
an
>> enforcement regime (e.g., trademark licensing a la VPNC or USB-IF) =
we're
>> stuck with what we get.
>>=20
>> -- T
>>=20
>> On 1/8/13 1:12 PM, "Stephen Kent"  wrote:
>>=20
>>> Tim,
>>>=20
>>> Your example, and the rationale for it, are just what I worry about.
>>> RP software is written badly, so a CA behaves poorly, to accommodate
>>> the bad RP software. This is just another example of why =
accmmodating
>>> bad software leads to more bad software ...
>>>=20
>>> Steve
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> 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
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix


From stefan@aaa-sec.com  Tue Feb 12 23:54:54 2013
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 7A64F21F8AA3 for ; Tue, 12 Feb 2013 23:54:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
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 OUBzPZrWPlUT for ; Tue, 12 Feb 2013 23:54:54 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id D095021F8AA0 for ; Tue, 12 Feb 2013 23:54:50 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id A04B53B5AE1 for ; Wed, 13 Feb 2013 08:54:49 +0100 (CET)
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 ETzaVLi5ExlD for ; Wed, 13 Feb 2013 08:54:13 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 2430B3B52E0 for ; Wed, 13 Feb 2013 08:51:38 +0100 (CET)
Received: (qmail 72820 invoked from network); 13 Feb 2013 07:51:22 -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 ; 13 Feb 2013 07:51:22 -0000
User-Agent: Microsoft-MacOutlook/14.3.0.121105
Date: Wed, 13 Feb 2013 08:51:18 +0100
From: Stefan Santesson 
To: Denis Pinkas 
Message-ID: 
Thread-Topic: [pkix] Review of 2560-bis draft 8. Answer to WGLC
In-Reply-To: <5118FDAB.5080804@bull.net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3443590283_11353265"
Cc: pkix 
Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC
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, 13 Feb 2013 07:54:54 -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_3443590283_11353265
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Denis,

I will review your comments.
Unfortunately I won't be able to do so this week.

This document has already been sent to the IESG with a request for
publicaion.
I will check in what way the comments will be handled.

/Stefan

From:  Denis Pinkas 
Date:  Monday, February 11, 2013 3:18 PM
To:  Stefan Santesson 
Cc:  pkix 
Subject:  Re [pkix] Review of 2560-bis draft 8. Answer to WGLC

>    =20
> =20
>  =20
>=20
> Stefan,
> =20
> =20
> =20
> I have finally revieed your disposition of comments. I have used draft 13=
.
> =20
> =20
> =20
> I will not adress the comments in sequence, but I will consider four
> categories:
> =20
> =20
> =20
> Category 1) Some comments which seem to be solved. Yes indeed, they may b=
e a
> ew of them !
> =20
> =20
> =20
> Category 2) Some comments which might possibly be soved at the WG level.
> =20
> =20
> =20
> Category 3) Some comments that I will address a the IETF last call level,
> rather than the WG last call level, since I disagree
>  that it is =B3new ways to say the same thing=B2 and it is likely to be a was=
t of
> time for both of us to argue again at the WG level
>  (these comments arecommented as =B3not broken=B2).
> =20
> =20
> =20
> Category 4) Some typos and editorials found whilereading draft 13.
> =20
> =20
> =20
> =20
> =20
>CATEGORY 1
> =20
> =20
> =20
> Comment 4 (was editorial).
> =20
> =20
> =20
> Comment 5.
> =20
> =20
> =20
> Cmment 6.=20
> =20
> =20
> =20
> Comment 19. Solved, since =B3unknown=B2 seems now to be also allowed for
> non-issued certificates
>  (even if the OCSP responder is using a direc access to the certificate
> database). See comment 8.
> =20
> =20
> =20
> Comment 13: Acceptable, since the text uses =B3MAY=B2.
> =20
> =20
> =20
> Comment 18.=20
> =20
> =20
> =20
> Comment 22.
> =20
> =20
> =20
> Comment 23.
 =20
> =20
> =20
> Comment 28.
> =20
> =20
> =20
> CATEGORY 1
> =20
> =20
> =20
> Comment 8: You ave changed the meaning of the revoked state in a way that=
 is
> not what I requested.
> =20
> =20
> =20
> The original text was:
>=20
> =20
> =20
>    The "revoked" state indicates that the certificate has been reoked
> =20
>    (either permanantly or temporarily (on hold)).
> =20
> =20
> =20
> The newtext is:
> =20
> =20
> =20
>    The "revoked" state indicates that the certificate has been revoked
> =20
>    either permanently ortemporarily on hold (i.e. the revocation reason
> =20
>    is certificateHold).
> =20
 =20
> =20
> By doing this, you do not allow any other case in the future to hav a
> temporary revocation: =B3temporarily on hold=B2
>  is not the same as =B3temporarily revoked=B2.
> =20
> =20
> =20
> I propose the following rewording:
> =20
> =20
>  >    The "revoked" state indicates that the certificate has been revoked
> =20
>   either permanently or temporarily (e.g. placed on hold).
> =20
> =20
> =20
> he way the text from draft 13 is now written seems to allow using either
> =B3unknown=B2 or =B3revoked=B2 for non-issued certificates.
>  If this is the intent, then the good news is that this dos not come anym=
ore
> into conflict with the French rules which apply for
> the Administration since OCSP responders from CAs used by the French
> Ministrieshaving a direct access to the database
>  of issued certificates will be able o use =B3unknown=B2, rather than =B3revoke=
d=B2
> and the reason code =B3onhold=B2.
> =20
> =20
> =20
> However,the current text is still mandating the use of Extended Revoked
> Definition, but he rational for its need it is very poor.
>  As I have said on the PKIX list, the fact that the revocation date is Ja=
nuary
> 1rst, 1970 is fully suffcient to know that we are in that
>  very special case, and you have not provied a rational to say the contra=
ry.
> =20
> =20
> =20
> So we could get rid of it, =8A ut the text from section 4.4.8 states:
> =20
> =20
> =20
>    This extension MAY bepresent in other responses to signal that the
> =20
>    responder implements te extended revoked definition in section 2.2.
> =20
> =20
> =20
> I have difficuties to understand what is really meant there (=B3other
> responses=B2 ?), since te text states:
> =20
> =20
> =20
>    This extension indicates that the responder supports the extended
> =20
    definition of the "revoked" status to also include non-isued
> =20
>    certificates according to section 2.2.
> =20
> =20
> =20
> Since both =B3unknown=B2 and revoked=B2 can be used, it would be desirable to b=
e
> able to include the same extension in both cases,
>  but in that case that extension should e renamed.
> =20
> =20
> =20
> I would propose to rename it: "non-issued certificate=B2 wich means that th=
e
> associated CA has no record of ever having issued
>  a cetificate with the certificate serial number in the request (I still
> consider it as unnecessary in the case of =B3revked=B2, but it would be
>  very useful in the case of =B3unknown=B2). Of course, the ext from section 4=
.4.8
> would need to be revised.
> =20
> =20
> =20
> I propose the following:
> =20
> =20
> =20
> 4.4.8  Nonissued certificate extension
> =20
> =20
> =20
>    This extension MUST be included in te OCSP response when the OCSP
> =20
>    responder knows that the CA identified n the request has no record
> =20
>    of ever having issued a certificate with he certificate serial
> =20
>    number indicated in the request.
> =20
> =20
> =20
>    Clients do not have to parse thisextension in order to determine
> =20
>    the status of certificates in responses.> =20
> =20
> =20
>    This extension is identified by the object identifier id-pkixocsp-
> =20
>    non-issued-cert.
> =20
> =20
> =20
>      id-pkix-ocsp-non-issued-cer OBJECT IDENTIFIER ::=3D {id-pkix-ocsp 9}
> =20
> =20
> =20
>    The value of the extension SHALL be NULL. This extension MUST NOT be
> =20
>   marked critical.
> =20
> =20
> =20
> Then the text on page 8 would need to be rearranged.
> =20
> =20
> =20
> The current text is:
> =20
> =20
> =20
>    his state MAY also be returned if the
> =20
>    associated CA has no record of eve having issued a certificate with
> =20
>    the certificate serial number in the request, using any current or
> =20
>   previous issuing key (referred to as a "non-issued" certificate in
> =20
>    his document).
> =20
> =20
> =20
>    The "unknown" state indicates that the responder doesn't know about
> =20
>    the certificate being requestd.
> =20
> =20
> =20
>    NOTE: The "revoked" state for known non-issued certificate erial
> =20
>          numbers is allowed in order to reduce the risk of relying
>=20
>          parties using CRLs as a fall back mechanism, which would be
> =20
>         considerably higher if an "unknown" response was returned.
> =20
> =20
> =20
>    When a responder responds revoked to a status request for a non-
> =20
>    ssued certificate, the responder MUST include the extended revoked
> =20
>    definition response extension (section 4.4.8) in the response,
> =20
>    inicating that the OCSP responder supports the extended definition
> =20
>    of revoked state to also cover non-issued certificates. In addition,
> =20
>    the SinleResponse related to this non-issued certificate;
> =20
> =20
> =20
>     - MUST provide the revocation reason certificteHold (6),
> =20
> =20
> =20
>     - MUST specify the revocationTime January 1, 170, and;
> =20
> =20
> =20
>     - MUST NOT include a CRL References extension (sectin 4.4.2) or any
> =20
>       CRL Entry Extensions (section 4.4.5).
> =20
> =20
> =20
> Proposed text for a replacement:
> =20
> =20
> =20
>    The "unknown" state indicats that the responder doesn't know about
> =20
>    the certificate being requestd.
> =20
> =20
> =20
>    If the OCSP responder knows that CA identified in the request has
> =20
>    no record of ever having issued a certificate with the certificate
> =20
>   serial number in the request, using any current or previous issuing
> =20
>    key(referred to as a "non-issued" certificate in this document),
> =20
>    the OCSP responder SHALL respond either =B3revoked =B3 or =B3unknown=B2.
> =20
> =20
> =20
>    Nte: The "revoked" state for known non-issued certificateserial
> =20
>    numbers is allowed in order to reduce the risk of relying parties
> =20
>    usng CRLs as a fall back mechanism, which would be possible when
> =20
>    the "unknon" response is returned.
> =20
> =20
> =20
>    When a resonder responds revoked or unknown to a status request
> =20
>    for a non-issued certficate, the responder MUST include the
> =20
>    non-issued certificate extension see section 4.4.8) in the
> =20
>    response.=20
> =20
> =20
> =20
>    When a responder responds revoked to a status request for a non-
> =20
>    issued cetificate, in addition, the responder:
> =20
> =20
> =20
>     - MUST provide the revcation reason certificateHold (6),
> =20
> =20
> =20
>     - MUST specify the revoationTime January 1, 1970, and;
> =20
> =20
> =20
>     - MUST NOT include a CRL Refeences extension (section 4.4.2) or any
> =20
>       CRL Entry Extensions (sectin 4.4.5).
> =20
> =20
> =20
> Finally, the last bullet on page 4 should be reworded:
> =20
> =20
> =20
> Current text:
> =20
> =20
>=20
>       o Section 4.4.8 specifies a new extension that indicates that the
> =20
>         responder supports the extendd use of the "revoked" response
> =20
>          for non-issued certificates defined in section2.2.
> =20
> =20
> =20
> Proposed replacement text:
> =20
> =20
> =20
>       o  Section 4.4.8 specifies a new extension that indicates that
> =20
>         the OCSP responder knows that CA identified in the request
> =20
>          has norecord of ever having issued a certificate with the
> =20
>          certificateserial number present in the request, as defined
> =20
>          in section 2.2.
> =20
> =20
> =20
> Comment 9: Solved, if the comment aove may be solved.
> =20
> =20
> =20
> Comment 20:  This comment is preliminary clssified by you as =B3not broken=B2=
.
> However, since you asked: =B3If you don=B9t replace 4.2.2.3,
>  then what really are you missing ?=B2, I will provide yo with an answer.
> =20
> =20
> =20
> This is the wrong way to state the question. Providing an ASN.1 syntax as=
 in
> 4.2.1 is not enough: the use of every parameter
>  MUS be explained using English words. So if you explain the use of every
> parameter fter the description of the ASN.1 syntax
>  in section 4.2.1. then section 4.2.2. is no more needed and thus can be
> deleted.
> =20
> =20
> =20
> The answer to your qestion =B3what is really missing=B2 is a description of t=
he
> use of every parameterlisted in the ASN.1 in section 4.2.1
> =20
> =20
> =20
> Comment 21.
> =20
> =20
> =20
> WhileI can agree in general with the intent of the text, I do not underst=
and
> the first sentence f the Note which speaks of =B3CA key rollover=B2
>  and is copied below:
> =20
> =20
> =20
    Note: CA key rollover is not prohibited when issuing a certificate
> =20
>         for an authorized responder for backwards compatibility with
> =20
>         RFC 2560 [RFC2560]. That is, it is not prohibited to issue a
> =20
>         certificate for an authorized respoer using a different
> =20
>          issuing key than the key used to issued the certificae being
> =20
>          checked for revocation. However, such practice is strngly
> =20
>          discouraged since clients are not required to recognize a
> =20
>          responder with such certificate a an authorized responder.
> =20
> =20
> =20
> I would propose to delete it, since it dos not add anything and thus to h=
ave:
> =20
> =20
> =20
>    Note: For backwards compatbility with RFC 2560 [RFC2560], it is
> =20
>          not prohibited to issuea certificate for an authorized
> =20
>          responder using a different issuing key than te key used to
> =20
>          issued the certificate being checked for revocation.
> =20
>          However, such practice is strongly discouraged since clients
> =20
>         are not required to recognize a responder with such
> =20
>          certificate as an authorized responder.
> =20
> =20
> =20
> Comment 24: The ASN.1 mdule in annex B.1 is still wrong, since it does no=
t
> define NoCheck.=20
> =20
>=20
> =20
> Comment 26: You asked for explanations. Let me provide you with an exampl=
e
> when CRLs are being used by the OCSP responder
>  in the background. The OCSP responder needs to ake sure that the CRL it =
uses
> is valid. If it is simply using published CRL
>  (i.e. no trusted link with the CA), it needs to make sure that the CA wh=
ich
> has issued the CRL has no been revoked.
> =20
> =20
> =20
> In France, there is a root CA for he Administration. However, the use of =
that
> root CA is optional. hus a Ministry may have its own root,
>  but may also have its key certified by he root CA of the Administration.=
 The
> OCSP responder may use the root CA of the Ministry,
>  while a relying party may use the root CA of the Administration (or the
> reverse) to validate the CRL for the targetcertificate.
>  Thus the revocation status will be different if the certificat of the CA=
 of
> the Ministry is revoked by the root CA of the Administration.
>=20
> =20
> =20
> CATEGORY 3
> =20
> =20
> =20
> Comments 2, 3, 7, 10, 12, 14, 15, 16, 17, 25 and 27.
> =20
> =20
> =20
> =20
> =20
> CATEGORY 4
> =20
> =20
> =20
> Page 4. The indentation of the bullets in section 1 is not niform.
>  Bullets 1, 4, 5 and 9 have problems.
> =20
> =20
> =20
> Page 4. The fact that there is now an Annex B.2 dealing wth the 2008 ASN.=
1
> syntax is missing. Tis should be added.
> =20
> =20
> =20
> Page 10. Change =B3Se further section 4.2.2.2=B2 into =B3See further section
> 4.2.2.2=B2
> =20
> =20
>=20
>  Denis
> =20
> =20
> =20
> =20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=20
> =20
> =20
> =20
 =20
>> =20
>> Denis,
>> =20
>>=20
>> =20
>> =20
>> Responding to your comments below.
>> =20
>>=20
>>  >> =20
>> However, one general remark to make recurring comments easier to underst=
ad.
>> =20
>>=20
>> =20
>> =20
>> The WG decided to adopt a minimalistic approach to updating RFC 2560. Th=
at
>> means tht=20
>> =20
>> 1. We don't change anything from RFC 2560 unless it is broken, or the
>> industry clearly need clarifications in order to avoid interopeability
>> issues.=20
>> 2. We etain the document structure of RFC 2560 as much as possible to al=
low
>> easy comparison o what the changes are in comparison with RFC 2560.
>> =20
>>=20
>>=20
>> =20
>> One can always think up more clever ways to write things out in words. B=
ut
>> tat also comes with a risk.
>> =20
>> The current words has been around for a long ime and we know from experi=
ence
>> which words worked to produce working implemntations, and which did not.
>> =20
>> Introducing new ways to say the same thing may introduce new problems an=
d
>> pople might disagree on what the new perfect wording should be. And this
>> could o on forever.
>> =20
>>=20
>> =20
>> =20
>> So when my reply is "Not broken", then hat is because the current wordin=
g
>> does not have such problems that is merts a change.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>> From:  Deis Pinkas 
>>  Date:  Sunday, January 20, 2013 5:12 PM
>>  To:  Stefan Santesson , Stephen Kent 
>  Cc:  pkix 
>>  Subject:  Re: [pkix] Review of 2560-bis daft 8. Answer to WGLC
>> =20
>> =20
>>=20
>> =20
>> =20
>>> =20
>>>  =20
>>>   =20
>>>=20
>>> Please find 32 comments on draft-ietf-pkix-rfc2560bis
>>> =20
>>> =20
>>> =20
>>> . The document states:
>>> =20
>>>  >> separately>
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>>Responded to separately.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>> =20
>>>=20
>>>=20
>>> =20
>>> =20
>>> =20
>>> 2. The current text from section 2 states
>>> =20
>>> =20
>>> =20
>>> 2.  Protocol Overview
>>> =20
>>> =20
>>> =20
>>>    In lieu of or as a suplement to checking against a periodic CRL, it
>>> =20
>>>    may be necessary to otain timely information regarding the
>>> =20
>>>    revocation status of a certificate (cf. RFC5280], Section 3.3).
>>> =20
>>>   Examples include high-value funds transfer or large stock trades.
>>> =20
>>> =20
>> =20
>>>    The Online Certificate Status Protocol (OCSP) enables applicationsto
>>> =20
>>>    determine the (revocation) state f an identified certificate. OCSP
>>> =20
>>>    may be used to satisfy some of the operationl requirements of
>>> =20
>>>    providing more timely revocation informaton than is possible with
>>> =20
>>>    CRLs and may also be used to obtain additional status information.
>>> =20
>>> =20
>>> =20
>>> This text is misleading beause readers may think that OCPS necessarily
>>> provides =B3timely information=B2.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>> =20
>>=20
>> =20
>> =20
>> "may" does not mean "necesarily".
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>> Proposed text replacement:
>>> =20
>>> =20
>>>=20
>>>=20
>>>    The Online Certificate Status Protocol (OCSP) is a client-server
>>> =20
>>>    protocol which enables applications to obtain the revocatio status
>>> =20
>>>    of one or more certificates either "good", "revoked", or "unknown".
>>> =20
>>> =20
>>> =20
>>>    Te revocation status may be provided by the server either using a
>>> =20
>>>    real time access to a database of issued certificates, o using a
>>> =20
>>>    batch access to a database of issued certificates, or using a
>>> =20
>>>    real time access to a database of revocation statuses of issued
>>> =20
>>>    certificates, or using a batch access to a database of revocation
>>> =20
>>>    statuses of issued certificats, or using CRLs, or using a
>>> =20
>>>    combination of base CRLsand delta CRLs.
>>> =20
>>> =20
>>> =20
>>>    In the first case, it is possible to obtain timely revocation status
>>> =20
>>>    information, whereasin the other cases, the freshness of the>>> =20
>>>    revocation status is not better than the mechanisms it is based on.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>
>>> 3. The current text from section 2 states:
>>> =20
>>>=20
>>> =20
>>>    An OCSP client issues a status request to an OCSP responder and
>>> =20
>>>   Suspends acceptance of the certificate in question until the
>>> =20
>>>    responder provides a response.
>>> =20
>>> =20
>>> =20
>>>   This protocol specifies the data that needs to be exchanged between
>>> =20
>>>    an application checking the status of a certificate and the server
>>> =20
>>>    providing that staus.
>>> =20
>>> =20
>>> =20
>>> Thus is insufficient for an overview. More details are needed to know w=
hat
>>> the document provides,
>>> in particular that te request may contain several requests for several
>>> certificates issued bydifferent CAs.
>>> The possibility of using extensions should also be advertised.
>>> =20
>>> =20
>>> =20
>>> Proposed text replacement:
>>> =20
>>> =20
>>> =20
>>>    Whenusing OCSP, an OCSP client issues a certificate revocation
>>> =20
>>>    status request to an OCSP responder for one o more certificates
>>> =20
>>>    issued by the same CA or for one or more cerificates issued by
>>> =20
>>>    different CAs and then suspends acceptance of the certificate(s)
>>> =20
>>>    i question until the responder provides a response.>>> =20
>>> =20
>>> =20
>>>    This document specifies the data that needs to be exchanged beteen
>>> =20
>>>    an application checking the status of a certificate and the serer
>>> =20
>>>    providing that status.
>>> =20
>>> =20
>>> =20
>>>    OCSP may also povide additional status information using
>>> =20
>>>    extensions.=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>>  >>  =20
>>=20
>> =20
>> =20
>> Not broken
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> . Page 6. Editorial. Punctuation and a CR/LF are missing.
>>> =20
>>> =20
>>> =20
>>>The text states:
>>> =20
>>> =20
>>> =20
>>>    3. the request contains the information needed by the responder If
>>> =20
>>>      any one of the prior conditions are not met, the OCSP responder
>>> =20
>>>      produces an error message; otherwise, it returns a definitive
>>> =20
>>>       response.
>>> =20
>>> =20
>>> =20
>>> It shold state:
>>> =20
>>> =20
>>> =20
>>>    4. the request contains the informationneeded by the responder.
>>> =20
>>> =20
>>> =20
>>>       If any one of the priorconditions are not met, the OCSP responder
>>> =20
>>>       produes an error message; otherwise, it returns a definitive
>>> =20
>>>       response.
>>> =20
>>>=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Fixed in draft 10
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 5. On page 7, the text states:
>>> =20
>>> =20
>>> =20
>>>    All definitive response messages SHALL be digitaly signed. The key
>>> =20
>>>    used to sign the response MUST belong to one of the following:
>>> =20
>>> =20
>>> =20
>>    -  the CA who issued the certificate in uestion
>>> =20
>>>    -  a Trusted Responder whose public key is trusted by the requester
>>>=20
>>>    -  a CA Designated Responder (Authorized Responder) who holds a
>>> =20
>>>       specially marked certificate issued directly by the CA, indicaing
>>> =20
>>>       that the responder may issue OCSP responses for that CA.
>>> =20
>>> =20
>>> =20
>>> The paragraph isambiguous on several aspects.
>>> =20
>>> =20
>>> =20
>>> Delegation  is addressed in at least three different places, but with
>>> differentterms and conditions.
>>>  If some one picks a sentence in one paragraph rather than another, it =
will
>>> lead to a different conclusion.
>>>  RFCs are supposed to be clear.
>>> =20
>>> =20
>>> =20
>>> On pge 10, the current text states in section 2.6 OCSP Signature Author=
ity
>>> Delegatin states:
>>> =20
>>> =20
>>> =20
>>>    The key that signs a certificate's status inforation need not be the
>>> =20
>>>    same  key that signed the certificate. A certificate's issuer
>>> =20
>>>    explicitly delegates OCSP signing authority by issuing a certificate
>>> =20
>>>    containing a unique value forextendedKeyUsage in the OCSP signer's
>>> =20
>>>    certificate. This certificte MUST be issued directly to the
>>> =20
>>>    responder by the cognizant CA.
>> =20
>>> =20
>>> =20
>>> On page 16, there is a section 4.2.2.2 called =B3Authorized Respnders=B2
>>> dealing with the same topic.
>>> =20
>>> =20
>>> =20
>>> Section 4.2.2.2 states:
>>> =20
>>> =20
>>> =20
>>>    The key that signs a certificate's status information need not be th=
e
>>> =20
>>>    same  key that sined the certificate. It is necessary however to
>>> =20
>>>    ensure that the entiy signing this information is authorized to do
>>> =20
>>>    so.  Therefore, a certificate's issuer MAY either sign the OCSP
>>> =20
>>>    respones itself or it MAY explicitly designatethis authority to
>>> =20
>>>    another entity.  OCSP  signing delegation SHALL be designated by the
>>> =20
>>>    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
>>> =20
>>>    extenson included in the OCSP response signer's certificate.  Tis
>>> =20
>>>    certificate MUST be issued directly by the CA that issued the
>>> =20
>>>   certificate in question.
>>> =20
>>> =20
>>> =20
>>>    The CA SHOULD use the same issuing key to issue a delegation
>>> =20
>>>    certificate as was used to sign the certificat being checked for
>>> =20
>>>    revocatio. Systems  relying on OCSP responses MUST recognize a
>>> =20
>>>    delegation  certificate as eing issued by the CA that issued the
>>> =20
>>>    certificate  in question only f the delegation certificate and the
>>> =20
>>>    certificate  being checked for revocation was signed by the same key=
.
>>> =20
>>> =20
>>> =20
>>> The last sentence above in yellow s the key sentence that is missing in=
 the
>>> two other sections.
>>> =20
>>> =20
>>> =20
>>> Most implementations only suport the case where the OCSP Responder rece=
ives
>> an OCSP certificate that is signed by the same key
>>> that was used to sign the targetcertificate. They do not support the ca=
se
>>> where the OCSP Responder receives n OCSP certificate
>>> that is signed by a key that is different from the one tat was used to =
sign
>>> the target certificate.
>>> =20
>>> =20
>>> =20
>>> It is inappropriate to have three sectins dealing with the same topic w=
ith
>>> a slightly different meaning.
>>> =20
>>>  >>> =20
>>> It is proposed the following.
>>> =20
>>> =20
>>> =20
>>> On page 7, after:>>> =20
>>> =20
>>> =20
>>>    -  a CA Designated Responder (Authorized Responder) who holds a
>>> =20
>>>       specially marke certificate issued directly by the CA, indicating
>>> =20
>>>       that the respnder may issue OCSP responses for that CA.
>>> =20
>>> =20
>>> =20
>>> it is proposed to add =B3(see section 4.2.2.2 for furthe details)=B2, so th=
at
>>> the reader knows that more details are provided laer on.
>>> =20
>>> =20
>>> =20
>>> Then we do not need two sections to address delgation which start with =
the
>>> same sentence:=20
>>> =20
>>> =20
>>> >>>  =B3The key that signs a certificate's status information need not be=
 the same
>>> key tht signed the certificate=B2.
>>> =20
>>> =20
>>> =20
>>> It is thus proposed to elete section 2.6.
>>> =20
>>> =20
>>> =20
>>> Section 4.2.2.2 will thus remain the single section providing full deta=
ils.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>> =20
>>  =20
>>=20
>> =20
>> =20
>> I have added references to section 4.2.2.2 in the quoted sections in 2.2=
 and
>> 2.6.
> =20
>> (will be included in draft 11)
>> =20
>>
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>> 6. Page 7, the text states:
>>> =20
>>>=20
>>> =20
>> =20
>>>    A definitive response message is composed of:
>>> =20
>>> =20
>>> =20
>>>    -  version of the response syntax
>>> =20
>>>    -  name of the respoder
>>> =20
>>>    -  responses for each of the certificates in a request
>>> =20
>>>    -  optional extensions
>>> =20
>>    -  signature algorithm OID
>>> =20
>>>    -  signature computed across hash of the response
>>> =20
>>> =20
>>> =20
>>> This description des not fit with the ASN.1 syntax which is detailed la=
ter
>>> on, and in particular:
>>> =20
>>> =20
>>> =20
>>>    ResponseData ::=3D SEQUENCE {
>>> =20
>>>       version              [0] EXPLICIT Version DEFAUT v1,
>>> =20
>>>       responderID              ResponderID,
>>> =20
>>>       producedAt               GeneralizedTime,
>>> =20
>>>       responses                SEQUENCE OF SingleResponse,
>>> =20
>>>       responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
>>> =20
>>> =20
>>> =20
>>> Proposed text replacement:
>>> =20
>>> =20
>>> =20
>>>    A definitive response message is composed of:
>> =20
>>> =20
>>> =20
>>>    - a response status and if there is no rror, the following:
>>> =20
>>>    - the version of the response syntax,
>>> =20
>>>   - an identifier of the OCSP server,
>>> =20
>>>    - the tie at which the response was produced,
>>> =20
>>>    - single responses for each of the target certificates,
>>> =20
>>>    - optional extensions,
>>> =20
>>>    - the signature algorithm OID,
>>> =20
>>>    - the signature computed across hash of the response, and
>>> =20
>>>    - optional certificates.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> This is an overview section. We ought not try to duplicate the level of
>> detail provided in the detailed protocol section.
>> =20
>> A "definitive response" according to tho 2.1 is a response to an error-f=
ree
>> request, so your first remark is redundant.
>> =20
>>=20
>> =20
>> =20
>> I have added a note about time to the current list, and changed "name" t=
o
>> identifier in bullet 2.
>> =20
>> (will be included in draft 11)
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 7. The text states on page 7:
>>> =20
>>> =20
>>> =20
>>>    The response for each of the certificates in a request consists of
>>> =20
>>> =20
>>> =20
>>>    -  target certificate identifier
>>> =20
>>>    -  certificate status value
>>> =20
>>>    -  response validity interval
>>> =20
>>>    -  optional extensions
>>> =20
>>> =20
>>> =20
>>> However,  there are no explanations for the purpose of these parameters=
 and
>>> how they should be processed.
>>> =20
>>> There are also no explanations on how to process a single response and =
how
>>> to verify that it is its presence within the signed structure
>>>  is valid or not valid. This is a major deficiency of the current
>>> description of RC 2560 where there is no explanation on how to validate
>>>  a single response.
>>> =20
>>> =20
>>> =20
>>> Text proposal to be added after:
>>> =20
>>> =20
>>> =20
>>>    The purpose of the identifier of the OCSP server is to allow OCSP
>>> =20
>>>    clients to find whether the definitive response was signed by a CA
>>> =20
>>>    or by an OCSP Responder.
>>> =20
>>> =20
>>> =20
>>>    The identifier of the OCSP server SHOULD either be the name or the
>>> =20
>>>    key from a CA, or the name or the key from a OCSP Responder.
>>> =20
>>> =20
>>> =20
>>>    Unless there exist local rules (which are outside the scope of this
>>> =20
>>>    document) for verifying that a single response is correctly signed,
>>> =20
>>>    the following applies:
>>> =20
>>> =20
>>> =20
>>>    When the identifier matches with the name of the CA which has issued
>>> =20
>>>    the target certificate or corresponds to the key used to issue the
>>> =20
>>>    target certificate, then a single response is correctly signed
>>> =20
>>>    only if the digital signature of the OCSP response is valid using th=
e
>>> =20
>>>    key used to sign the target certificate.
>>> =20
>>> =20
>>> =20
>>>    When the identifier does not match with the name of the CA which has
>>> =20
>>>    issued the target certificate or does not correspond to the key used
>>> =20
>>>    to issue the target certificate, then an single response is correctl=
y
>>> =20
>>>    signed only if :
>>> =20
>>> =20
>>> =20
>>>          (a) there exists in the response an OCSP certificate issued by
>>> =20
>>>              the CA which has issued the target certificate which is
>>> =20
>>>              signed by the same key as the one used to issue the
>>> =20
>>>              target  certificate, and
>>> =20
>>> =20
>>> =20
>>>          (b) the digital signature of the OCSP response is valid using
>>> =20
>>>              the  subjectPublicKey contained in this OCSP certificate.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>> All of this is already covered by the document.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 8. The text states on page 7:
>>> =20
>>> =20
>>> =20
>>>    The "revoked" state indicates that the certificate has been revoked
>>> =20
>>>    (either permanently or temporarily (on hold)). This state MAY also b=
e
>>> =20
>>>    returned if the responder knows that the requested certificate has
>>> =20
>>>    never been issued during the history of the associated CA using  any
>>> =20
>>>    current or previous issuing key.
>>> =20
>>> =20
>>> =20
>>> The text is ambiguous because there are two embedded parenthesis and it=
 is
>>> unclear whether the inner parenthesis means =B3i.e=B2 or =B3e.g=B2.
>>>  This single sentence may let think that on hold is the single case for
>>> temporarily revocation. Since neither X.509 nor RFC 5280 address
>>>  the case of a temporary revocation in the context of an OCSP response =
(but
>>> only in the context of CRLs), we are able to add another case
>>>  of temporary revocation which will only apply in the context of OCSP.
>>> =20
>>> =20
>>> =20
>>> The above sentence using the terms =B3never been issued during the histor=
y of
>>> the associated CA =B3does not capture the fact
>>>  that it could be issued in the future, hence why using =B3not yet been u=
sed=B2
>>> would be more appropriate.
>>> =20
>>> =20
>>> =20
>>> Finally, it would have been more logical to use =B3unknown=B2. So it is
>>> important to add a note to explain why we have chosen that case for =B3le=
gacy
>>> clients=B2,=20
>>>  otherwise the people who have not participate to the exchanges will no=
t
>>> understand.
>>> =20
>>> =20
>>> =20
>>> Proposed text replacement:
>>> =20
>>> =20
>>> =20
>>>    The "revoked" state indicates that the certificate has been revoked,
>>> =20
>>>    either permanently or temporarily.
>>> =20
>>> =20
>>> =20
>>>    A certificate may be temporarily revoked either because it is
>>> =20
>>>    placed on hold (i.e. the revocation reason is certificateHold) or
>>> =20
>>>    because the responder is able to know, using a positive list of
>>> =20
>>>    issued certificates, that the serial number from the requested
>>> =20
>>>    certificate has not yet been used by the CA to issue a certificate
>>> =20
>>>    (i.e. the revocation reason is notIssuedOrIrregularlyIssued).
>>> =20
>>> =20
>>> =20
>>> NOTE: The "revoked" state is used rather than the =B3unknown=B2 state, to
>>> =20
>>>       make sure that relying parties that were conformant to RFC 2560
>>> =20
>>>       will not use CRLs as a fall back mechanism.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> I removed the double parenthesis and adopted your clarification with reg=
ard
>> to "on hold".=20
>> =20
>>=20
>> =20
>> =20
>> The text in draft 10 has changed from what you have commented on. I beli=
eve
>> that text is better.
>> =20
>>=20
>> =20
>> =20
>> You "Note" has problems.
>> =20
>> 1. We do not prevent responders to respond "unknown" if their assessment=
 is
>> that this is an appropriate response, considering what they know about t=
he
>> requested serial number. Thus the term "is used" is misleading.
>> 2. This mechanisms does not "make sure" that the clients do anything. It=
's up
>> to the discretion of the relying party to decide what source of revocati=
on
>> checking they rely on. This does however reduce the risk of clients fall=
ing
>> back to CRL:s=20
>> 3. This mechanism is not just relevant to old clients, but also to new o=
ne
>> for the same reason.
>> =20
>>=20
>> =20
>> =20
>> I have adopted a modified version of your Note:
>> =20
>>=20
>> =20
>> =20
>> =20
>>    NOTE: The "revoked" state for known non-issued certificate serial
>> =20
>>          numbers is allowed in order to reduce the risk of relying
>> =20
>>          parties using CRLs as a fall back mechanism, which would be
>> =20
>>          considerably higher if an "unknown" response was returned.
>> =20
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 9. The text states on page 8:
>>> =20
>>> =20
>>> =20
>>>    When a responder responds revoked to a status request for a non-
>>> =20
>>>    issued certificate, the responder MUST also;
>>> =20
>>> =20
>>> =20
>>>     - include the extended revoked definition response extension
>>> =20
>>>       (section 4.8), indicating that the OCSP responder supports the
>>> =20
>>>       extended definition of revoked state to also cover non-issued
>>> =20
>>>       certificates,
>>> =20
>>> =20
>>> =20
>>>     - provide the revocation reason certificateHold (6), and;
>>> =20
>>> =20
>>> =20
>>>     - specify the revocation date January 1, 1970.=20
>>> =20
>>> =20
>>> =20
>>> As already explained on the PKIX list, using the revocation reason=20
>>> certificateHold is not appropriate=20
>>>  because it changes the meaning of certificateHold.=20
>>> =20
>>> =20
>>> =20
>>> The extended revoked definition response extension is a means to signal=
 that=20
>>> it not a true certificate hold but a =B3not issued certificate=B2.=20
>>>  Legacy applications cannot take advantage of it.=20
>>> =20
>>> =20
>>> =20
>>> Some applications which handle non repudiation enter a waiting state wh=
en=20
>>> the revocation reason certificateHold is used thus=20
>>>  it is not appropriate to overload the meaning.
>>> =20
>>> =20
>>> =20
>>> It is possible to use another enumeration for signalling that specific =
case:
>>> =20
>>> notIssuedOrIrregularlyIssued  (7).
>>> =20
>>> =20
>>> =20
>>> Thus for new applications it would be much better to use=20
>>> notIssuedOrIrregularlyIssued (7) as already proposed on the PKIX list.
>>> =20
>>> =20
>>> =20
>>> The above sentence uses the text:=20
>>> =20
>>> =20
>>> =20
>>> =B3a status request for a non-issued certificate=B2=20
>>> =20
>>> =20
>>> =20
>>> whereas it would be more appropriate to state:=20
>>> =20
>>> =20
>>> =20
>>> =B3a status request for a serial number which has not been used by the CA=
 or=20
>>> used irregularly to issue a certificate=B2.
>>> =20
>>> =20
>>> =20
>>> Placing the ASN.1 description at such a place in the document is=20
>>> inappropriate since the ASN.1 structures have not yet been described.=20
>>> Thus only the functional aspects should be mentioned, but not the ASN.1=
=20
>>> implications.
>>> =20
>>> =20
>>> =20
>>> BTW, the description should follow the same order as the ASN.1. This is=
 not=20
>>> the case.=20
>>> =20
>>> =20
>>> =20
>>> This text should be deleted from this section and the appropriate text=20
>>> should be added when the parameters of the response are described.=20
>>> =20
>>> =20
>>> =20
>>> The text proposed in the previous comment should be sufficient at this =
time=20
>>> of reading.
>>> =20
>>> =20
>>> =20
>>> In addition, section 4.4.8  Extended  Revoked Definition should be dele=
ted.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> The referred text has been updates in draft 09.
>> =20
>>=20
>> =20
>> =20
>> This has been discussed on the list and you have yet to convince the lis=
t of=20
>> your new reason code.
>> =20
>> I disagree as the risk of running into problems with the deployed base o=
f=20
>> application is hugely larger with introduction of a new reason code, rat=
her=20
>> than using certificateHold.
>> =20
>> No application should be broken, since no application have business aski=
ng=20
>> for non-issued cert serial numbers in the first place. Secondly, no=20
>> application can assume that a certificateHold reason will be cleared any=
 time=20
>> soon.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 10. The text states on page 8:
>>> =20
>>> =20
>>> =20
>>> 2.4  Semantics of thisUpdate, nextUpdate and producedAt
>>> =20
>>> =20
>>> =20
>>> This section is misplaced. At this time of reading, the reader does not=
 know=20
>>> that thisUpdate, nextUpdate and producedAt are values=20
>>>  used by the ASN.1 structures. It is appropriate to describe what these=
s=20
>>> parameters mean when the ASN.1 syntax is described.=20
>>>  The current ASN.1 syntax is very badly described. One would expect tha=
t=20
>>> after every ASN.1 structure description every parameter is described.=20
>>>  Unfortunately this is not the case.=20
>>> =20
>>> =20
>>> The text from this section is not aligned with the text that is present=
 in=20
>>> section 4.2.2.1.=20
>>> =20
>>> =20
>>> =20
>>> In particular, in section 2.4:
>>> =20
>>> =20
>>> =20
>>>    If nextUpdate is not set, the responder is indicating that newer
>>> =20
>>>    revocation information is available all the time.
>>> =20
>>> =20
>>> =20
>>> While in section 4.2.2.1:
>>> =20
>>> =20
>>> =20
>>>    Responses where the nextUpdate value is not set are equivalent=20
>>> =20
>>>    to a CRL with no time for nextUpdate (see Section 2.4).
>>> =20
>>> =20
>>> =20
>>> It is not appropriate to have two different descriptions in two differe=
nt=20
>>> places.
>>> =20
>>> =20
>>> =20
>>> Delete section 2.4. See comment number 19 for the description of these=20
>>> parameters.
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>> The current text segments fits well into a protocol overview section.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 11. Section 2.5 is also misplaced. They use values from the ASN.1 synta=
x=20
>>> which has not yet been described.=20
>>>  They should be moved or incorporated in the document once the ASN.1=20
>>> description has been done.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 12. Remainder: Section 2.6 should be deleted (see comment number 5).
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 13. Section 2.7 states:
>>> =20
>>> =20
>>> =20
>>> 2.7  CA Key Compromise
>>> =20
>>> =20
>>> =20
>>>    If an OCSP responder knows that a particular CA's private key has
>>> =20
>>>    been compromised, it MAY return the revoked state for all
>>> =20
>>>    certificates issued by that CA.
>>> =20
>>> =20
>>> =20
>>> This section is misleading and should be removed. The reason is the=20
>>> following:
>>> =20
>>> =20
>>> =20
>>> The relying party must verify that the singleResponse is signed by a=20
>>> responder which is entitled to do so.
>>> =20
>>> =20
>>> =20
>>> a) If the CA key has been compromised and if the response is signed by =
that=20
>>> CA key then the singleResponse will be discarded=20
>>>  when performing the certification path validation whatever the content=
 of=20
>>> the response may be.
>>> =20
>>> =20
>>> =20
>>> b) If the CA key which has issued the OCSP certificate has been comprom=
ised=20
>>> and if the response is signed by the key present=20
>>>  in the OCSP certificate then the singleResponse will be discarded when=
=20
>>> performing the certification path validation
>>>  whatever the content of the response may be.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> Security  must be provided using the validation of the certification pa=
th.=20
>>> Thus it does not matter what the OCSP responder states.
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>> An OCSP responder does not have to be chained to the broken CA. The rely=
ing=20
>> party may have other trust configuration at choice.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>>=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 14. The text states on page 11:
>>> =20
>>> =20
>>> =20
>>> 3.2  Signed Response Acceptance Requirements
>>> =20
>>> =20
>>> =20
>>>    Prior to accepting a signed response as valid, OCSP clients SHALL
>>> =20
>>>    confirm that:
>>> =20
>>> =20
>>> =20
>>>    1. The certificate identified in a received response corresponds to
>>> =20
>>>       that which was identified in the corresponding request;
>>> =20
>>> =20
>>> =20
>>>    2. The signature on the response is valid;
>>> =20
>>> =20
>>> =20
>>>    3. The identity of the signer matches the intended recipient of the
>>> =20
>>>       request.
>>> =20
>>> =20
>>> =20
>>>    4. The signer is currently authorized to sign the response.
>>> =20
>>> =20
>>> =20
>>>    5. The time at which the status being indicated is known to be
>>> =20
>>>       correct (thisUpdate) is sufficiently recent.
>>> =20
>>> =20
>>> =20
>>>    6. When available, the time at or before which newer information wil=
l
>>> =20
>>>       be available about the status of the certificate (nextUpdate) is
>>> =20
>>>       greater than the current time.
>>> =20
>>> =20
>>> =20
>>> This section is misplaced since it uses terms from the ASN.1 syntax and=
 the=20
>>> protocol description has not yet been made,=20
>>>  since it is the next section 4. Its text is not correct either.=20
>>> =20
>>> =20
>>> =20
>>> This description does not take into account the fact that a=20
>>> BasicOCSPResponse may contain one or several SingleResponses.=20
>>>  In particular, the sentence =B3The signer is currently authorized to sig=
n the=20
>>> response=B2 is misleading because a signer=20
>>>  may be authorized to include some SingleResponses but not necessarily =
all=20
>>> of them.=20
>>> =20
>>> =20
>>> =20
>>> The appropriate explanations should be done after the description of th=
e=20
>>> response, when describing the processing of the response.
>>> =20
>>> =20
>>> =20
>>> Delete that section.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 15. On page 12, after the ASN.1 description, the only parameters which =
are=20
>>> described are:=20
>>> =20
>>> hashAlgorithm, issuerNameHash,  issuerKeyHash and serialNumber.
>>> =20
>>> =20
>>> =20
>>> This is insufficient.  In order to cover the full list of parameters, t=
he=20
>>> following text is proposed:
>>> =20
>>> =20
>>> =20
>>>    requestorName is optional and MAY be used by the server for access=20
>>> =20
>>>    control and audit purposes.
>>> =20
>>> =20
>>> =20
>>>    requestList contains one or more single requests.
>>> =20
>>> =20
>>> =20
>>>    requestExtensions is OPTIONAL.  Any  specific extension is OPTIONAL.
>>> =20
>>>    The critical flag SHOULD NOT be set for any of them. Section 4.4=20
>>> =20
>>>    suggests several useful extensions.  Additional extensions MAY be=20
>>> =20
>>>    defined in additional RFCs.
>>> =20
>>> =20
>>> =20
>>>    reqCert contains the identifier of a target certificate.
>>> =20
>>> =20
>>> =20
>>>    issuerNameHash is the hash of the Issuer's distinguished name.  The=20
>>> =20
>>>    hash shall be calculated over the DER encoding of the issuer's name=20
>>> =20
>>>    field in the certificate being checked.=20
>>> =20
>>> =20
>>> =20
>>>    issuerKeyHash is the hash of the Issuer's public key.  The hash=20
>>> =20
>>>    shall be calculated over the value (excluding tag and length) of the=
=20
>>> =20
>>>    subject public key field in the issuer's certificate.  The hash=20
>>> =20
>>>    algorithm used for both these hashes, is identified in=20
>>> =20
>>>    hashAlgorithm.=20
>>> =20
>>> =20
>>> =20
>>>       The primary reason to use the hash of the CA's public key in=20
>>> =20
>>>       addition to the hash of the CA's name, to identify the issuer,=20
>>> =20
>>>       is that it is possible that two CAs may choose to use the same=20
>>> =20
>>>       name (uniqueness in the Name is a recommendation that cannot be=20
>>> =20
>>>       enforced).  Two CAs will never, however, have the same public key=
=20
>>> =20
>>>       unless the CAs either explicitly decided to share their private=20
>>> =20
>>>       key, or the key of one of the CAs was compromised.
>>> =20
>>> =20
>>> =20
>>>    serialNumber is the serial number of the certificate for which=20
>>> =20
>>>    status is being requested.
>>> =20
>>> =20
>>> =20
>>>    singleRequestExtensions  is OPTIONAL.  Any  specific extension is=20
>>> =20
>>>    OPTIONAL.  The critical flag SHOULD NOT be set for any of them.=20
>>> =20
>>> =20
>>> =20
>>>    The requestor MAY choose to sign the OCSP request.  In that case, th=
e
>>> =20
>>>    signature is computed over the tbsRequest structure.  If the request
>>> =20
>>>    is signed, the requestor SHALL specify its name in the requestorName
>>> =20
>>>    field.  Also, for signed requests, the requestor MAY include
>>> =20
>>>    certificates that help the OCSP responder verify the requestor's
>>> =20
>>>    signature in the certs field of Signature.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>> The current text is short, but it is actually sufficient from the contex=
t of=20
>> the ASN.1 definitions of the section. This is a detailed protocol sectio=
n and=20
>> the reader need to understand ASN.1 in any case to understand and implem=
ent=20
>> the section.
>> =20
>> The information about criticality is already covered in the extension=20
>> section.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 16. Section 4.1.2 is called: =B3Notes on the Request Syntax=B2
>>> =20
>>> =20
>>> =20
>>> The first paragraph has been moved after the description of issuerKeyHa=
sh=20
>>> and thus is no more needed.
>>> =20
>>> =20
>>> =20
>>> The second paragraph has been moved after the description of=20
>>> requestExtensions.=20
>>>  However, the sentence=20
>>>  =B3 Unrecognized extensions MUST be ignored (unless they have the critic=
al=20
>>> flag set and are not understood)=B2=20
>>>  has been deleted since it applies to the OCSP responder and not to the=
 OCSP=20
>>> client. Thus it is no more needed.
>>> =20
>>> =20
>>> =20
>>> The third paragraph applies to signed requests. However, it should belo=
ng to=20
>>> a section dedicated on how clients should build OCPS requests,=20
>>>  which is currently missing. See the next comment.
>>> =20
>>> =20
>>> =20
>>> This section should be deleted.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 17. There should be a new section called: =B3Requirements  for OCSP clien=
ts=B2.=20
>>> =20
>>> =20
>>> =20
>>> It is important first to re-advertise that the request may be about sev=
eral=20
>>> certificates.=20
>>>  Thus it is important to describe the process for building a request, w=
hich=20
>>> is currently missing.
>>> =20
>>> =20
>>> =20
>>>    An OCSP request allows getting in the same response the revocation=20
>>> =20
>>>    status of one or more certificates.  In order to request the=20
>>> =20
>>>    status of one or more certificates in a single request, OCSP=20
>>> =20
>>>    clients SHALL follow the following rules :
>>> =20
>>> =20
>>> =20
>>>    For each candidate certificate, OCSP clients SHALL verify=20
>>> =20
>>>    whether there exists a locally defined rule for the certificate in=20
>>> =20
>>>    question which indicates the URI where the OCSP responder is=20
>>> =20
>>>    located.  If this rule exists, it SHALL be followed.=20
>>> =20
>>> =20
>>> =20
>>>    Otherwise, OCSP clients SHALL determine whether the candidate=20
>>> =20
>>>    certificate contains an AIA extension with an accessMethod which=20
>>> =20
>>>    contains the id-ad-ocsp OID.  If  it is the case, the accessLocation=
=20
>>> =20
>>>    contains a uniformResourceIdentifier (URI) which indicates the=20
>>> =20
>>>    location of the OCSP server for that certificate.=20
>>> =20
>>> =20
>>> =20
>>>    Certificates that contain the same URI MAY be grouped in a single=20
>>> =20
>>>    request.
>>> =20
>>> =20
>>> =20
>>> Note:  For each candidate certificate, when performing the path=20
>>> =20
>>>        validation  algorithm, the OCSP client SHOULD verify that the=20
>>> =20
>>>        current time is within the validity period of the target=20
>>> =20
>>>        certificate.  Certificates which are outside their validity=20
>>> =20
>>>        period SHOULD NOT be included in the request.
>>> =20
>>> =20
>>> =20
>>>    The requestor MAY choose to sign the OCSP request. In that case, the
>>> =20
>>>    signature is computed over the tbsRequest structure. If the request
>>> =20
>>>    is signed, the requestor SHALL specify its name in the requestorName
>>> =20
>>>    field. Also, for signed requests, the requestor MAY include
>>> =20
>>>    certificates that help the OCSP responder verify the requestor's
>>> =20
>>>    signature in the certs field of Signature.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>> =20
>> Your text may provide guidance that could be useful to some implementers=
, but=20
>> is completely beyond this document and further, not generally applicable=
 or=20
>> true.
>> =20
>> As an example, an organisation may setup an in house locally configured =
OCSP=20
>> responder that responds to all certificates "out there" that is relevant=
 to=20
>> that organisation.
>> =20
>> Such clients would just blindly send OCSP requests to their local respon=
der,=20
>> disregarding any information in the cert.
>> =20
>> It's totally beyond this spec to have an opinion about this.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 18. The text states on page 14:
>>> =20
>>> =20
>>> =20
>>>    The responder MAY include certificates in the
>>> =20
>>>    certs field of BasicOCSPResponse that help the OCSP client verify th=
e
>>> =20
>>>    responder's signature. If no certificates are included then certs
>>> =20
>>>    SHOULD be absent.
>>> =20
>>> =20
>>> =20
>>> While this sentence is true, it is not sufficient. In order to allow=20
>>> verifying every SingleResponse,=20
>>>  it is important to include the relevant certificates which are pertine=
nt to=20
>>> every SingleResponse.
>>> =20
>>> =20
>>> =20
>>> Proposed  full text replacement:
>>> =20
>>> =20
>>> =20
>>>    The responder MAY include certificates in the certs field of=20
>>> =20
>>>    BasicOCSPResponse  that help the OCSP client verify the responder's=20
>>> =20
>>>    signature.
>>> =20
>>> =20
>>> =20
>>>    For every SingleResponse where the responder is not a CA, the=20
>>> =20
>>>    responder SHALL include the relevant OCSP certificate in the certs=20
>>> =20
>>>    field of BasicOCSPResponse in order to allow the OCSP client=20
>>> =20
>>>    verifying the responder was entitled to include that SingleResponse=20
>>> =20
>>>    in the signed BasicOCSPResponse.
>>> =20
>>> =20
>>> =20
>>>    If no certificates are included then certs SHOULD be absent.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>> =20
>> This requirement would break backwards compatibility with RFC 2560.
>> =20
>> Further this would not be needed for a locally configured responder.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 19. Page 15. The ASN.1 syntax should be changed in order to be able to =
use=20
>>> the enumeration case 7 that is not used for CRLs.=20
>>>  This leads to the following change:
>>> =20
>>> =20
>>> =20
>>> Current text:
>>> =20
>>> =20
>>> =20
>>>        revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }
>>> =20
>>> =20
>>> =20
>>> Proposed  text change:
>>> =20
>>> =20
>>> =20
>>> Current text:
>>> =20
>>> =20
>>> =20
>>>        revocationReason    [0]     EXPLICIT RevocationReason OPTIONAL }
>>> =20
>>> =20
>>> =20
>>> RevocationReason ::=3D  ENUMERATED {
>>> =20
>>>         unspecified                    (0),
>>> =20
>>>         keyCompromise                  (1),
>>> =20
>>>         cACompromise                   (2),
>>> =20
>>>         affiliationChanged             (3),
>>> =20
>>>         superseded                     (4),
>>> =20
>>>         cessationOfOperation           (5),
>>> =20
>>>         certificateHold                (6),
>>> =20
>>>         notIssuedOrIrregularlyIssued    (7),
>>> =20
>>>         removeFromCRL                  (8),
>>> =20
>>>         privilegeWithdrawn             (9),
>>> =20
>>>         aACompromise                  (10) }
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>> =20
>> You have to convince the list about your new reason code.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 20. Page 15. After the ASN.1 syntax, there is no description of every=20
>>> parameter, neither on its use=20
>>>  (except a few words in section 4.2.2.1 Time about thisUpdate, nextUpda=
te=20
>>> and producedAt).
>>> =20
>>> =20
>>> =20
>>> Every parameter needs to be described and explained.
>>> =20
>>> =20
>>> =20
>>>    responderID indicates either the name or the key from a CA, or the=20
>>> =20
>>>    name or the key from a OCSP Responder.
>>> =20
>>> =20
>>> =20
>>>    producedAt indicates the time at which this response was signed.
>>> =20
>>> =20
>>> =20
>>>    responses contains one or more single responses.
>>> =20
>>> =20
>>> =20
>>>    responseExtensions is OPTIONAL.  Any  specific extension is OPTIONAL=
.
>>> =20
>>>    The critical flag may or may not be set.
>>> =20
>>> =20
>>> =20
>>>    certID is usually a copy of the same field which was placed in the=20
>>> =20
>>>    request, but for OCSP responders which pre-produce signed responses=20
>>> =20
>>>    certID may be the identifier of a target certificate that was not=20
>>> =20
>>>    present in the request (see the end of section 4.2).
>>> =20
>>> =20
>>> =20
>>>    certStatus indicates the status of the certificate: either good,=20
>>> =20
>>>    revoked or unknown.
>>> =20
>>> =20
>>> =20
>>>    thisUpdate indicates the time at which the status being indicated=20
>>> =20
>>>    is known to be correct.
>>> =20
>>> =20
>>> =20
>>>    nextUpdate indicates the time at or before which newer information=20
>>> =20
>>>    will be available about the status of the certificate.  If=20
>>> =20
>>>    nextUpdate is not set, the server is indicating that newer=20
>>> =20
>>>    revocation information is available all the time.=20
>>> =20
>>> =20
>>> =20
>>>    If nextUpdate is set, it often corresponds to the {thisUpdate,=20
>>> =20
>>>    nextUpdate} interval in CRLs.  Responses whose nextUpdate value is=20
>>> =20
>>>    earlier than the local UTC time value SHOULD be considered=20
>>> =20
>>>    unreliable.  Responses whose thisUpdate time is later than the local=
=20
>>> =20
>>>    UTC time SHOULD be considered unreliable.
>>> =20
>>> =20
>>> =20
>>>    singleExtensions is OPTIONAL.  Any  specific extension is OPTIONAL.
>>> =20
>>>    The critical flag SHOULD NOT be set for any of them.
>>> =20
>>> =20
>>> =20
>>>    revocationTime  indicates the time at which the certificate was=20
>>> =20
>>>    revoked.
>>> =20
>>> =20
>>> =20
>>>    revocationReason is OPTIONAL.  It  includes all the cases that are=20
>>> =20
>>>    present in CRLReason used for CRLs and an additional case 7 which is
>>> =20
>>>    not used for CRLs.  Case 7 is called notIssuedOrIrregularlyIssued.=20
>>> =20
>>> =20
>>> =20
>>>       - "notIssued" corresponds to the case where the certificate=20
>>> =20
>>>          serial number that was sent was erroneous and has not yet=20
>>> =20
>>>          been used by the CA at the time of the query,
>>> =20
>>> =20
>>> =20
>>>       - "irregularlyIssued" corresponds to the case where the=20
>>> =20
>>>          certificate  serial number that was sent really exists in a=20
>>> =20
>>>          certificate that is correctly signed, but to its knowledge=20
>>> =20
>>>          the CA has not issued a certificate with such a serial=20
>>> =20
>>>          number.  As an example, it may have been issued by the CA=20
>>> =20
>>>          because the RA was compromised.=20
>>> =20
>>> =20
>>> =20
>>>    When a responder responds revoked to a status request for which it=20
>>> =20
>>>    knows that the serial number has not been used by the CA or has=20
>>> =20
>>>    been irregularly used irregularly to issue a certificate, then=20
>>> =20
>>>    in RevokedInfo the responder MUST:
>>> =20
>>> =20
>>> =20
>>>       - specify the revocationTime :  January 1, 1970,
>>> =20
>>>       - provide the revocationReason: notIssuedOrIrregularlyIssued (7).
>>> =20
>>> =20
>>> =20
>>>    and in SingleResponse the responder MUST NOT include the nextUpdate.
>>> =20
>>> =20
>>> =20
>>>    The response MUST include a SingleResponse for each certificate in
>>> =20
>>>    the request and SHOULD NOT include any additional SingleResponse
>>> =20
>>>    elements.  However, there is one exception:=20
>>> =20
>>> =20
>>> =20
>>>       OCSP responders MAY pre-produce signed responses specifying the=20
>>> =20
>>>       status of certificates at a specified time.  The time at which=20
>>> =20
>>>       the status was known to be correct SHALL be reflected in the=20
>>> =20
>>>       thisUpdate field of the response.=20
>>> =20
>>> =20
>>> =20
>>>       OCSP responders that pre-generate status responses MAY return=20
>>> =20
>>>       responses that include additional SingleResponse elements if
>>> =20
>>>       necessary to improve response pre-generation performance or cache
>>> =20
>>>       efficiency (as permitted in [RFC5019]).
>>> =20
>>> =20
>>> =20
>>> Since the text above provides all the explanations at the level of the =
ASN.1=20
>>> parameters, the general text=20
>>>  from section 4.2.2.3 Basic Response is no more need and should be dele=
ted.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Preliminary I would say "not broken".
>> =20
>> If you don't replace 4.2.2.3, then what really are you missing?
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 21. 0n page 16, there is a section 4.2.2.2 called =B3Authorized Responder=
s=B2
>>> =20
>>> =20
>>> =20
>>> Section 4.2.2.2 states:
>>> =20
>>> =20
>>> =20
>>>    (=8A)
>>> =20
>>>    This certificate MUST be issued directly by the CA that issued the
>>> =20
>>>    certificate in question.
>>> =20
>>> =20
>>> =20
>>>    The CA SHOULD use the same issuing key to issue a delegation
>>> =20
>>>    certificate as was used to sign the certificate being checked for
>>> =20
>>>    revocation. Systems relying on OCSP responses MUST recognize a
>>> =20
>>>    delegation certificate as being issued by the CA that issued the
>>> =20
>>>    certificate in question only if the delegation certificate and the
>>> =20
>>>    certificate being checked for revocation was signed by the same key.
>>> =20
>>> =20
>>> =20
>>> This section would need to reformatted to address CA requirements first=
 and=20
>>> then OCSP responder requirements:
>>> =20
>>> =20
>>> =20
>>>    (=8A)
>>> =20
>>>    This certificate MUST be issued directly by the CA that issued the
>>> =20
>>>    certificate in question.  The CA SHOULD use the same issuing key to=20
>>> =20
>>>    issue a delegation certificate as was used to sign the certificate=20
>>> =20
>>>    being checked for revocation.=20
>>> =20
>>> =20
>>> =20
>>>    Systems relying on OCSP responses MUST be able to recognize a=20
>>> =20
>>>    delegation certificate as being issued by the CA that issued the=20
>>> =20
>>>    certificate in question if the delegation certificate and=20
>>> =20
>>>    the certificate being checked were signed by the same key.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> I disagree. The CA is actually free to do anything, but cannot expect th=
e=20
>> client to recognise the responder as authorised unless the same private =
key=20
>> is used.
>> =20
>> The current text places the requirement where they belong.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 22. On page 17, the text states:
>>> =20
>>> =20
>>> =20
>>>    They MUST reject the
>>> =20
>>>    response if the certificate required to validate the signature on th=
e
>>> =20
>>>    response fails to meet at least one of the following criteria:
>>> =20
>>> =20
>>> =20
>>> This is ambiguous. It is inappropriate to have a negative statement lik=
e=20
>>> =B3They MUST reject=B2.=20
>>>  The sentence should be turned in the positive form =B3They SHALL accept=B2=
=20
>>> =20
>>> =20
>>> =20
>>> Since the ASN.1 syntax has now be described, it is possible to be more=20
>>> specific.
>>> =20
>>> =20
>>> =20
>>> The first occurrence of the word =B3response=B2 should be changed into=20
>>> =B3singleResponse=B2, while the second occurrence=20
>>>  of the word =B3response=B2 should be changed into =B3ResponseData=B2
>>> =20
>>> =20
>>> =20
>>> Proposed  text replacement:
>>> =20
>>> =20
>>> =20
>>>    They SHALL accept a singleResponse if the certificate required to=20
>>> =20
>>>    validate the signature placed on the ResponseData meets one of the=20
>>> =20
>>>    following criteria:
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>>=20
>> =20
>> =20
>> No, this change is not backwards compatible.
>> =20
>> So state the requirements for rejection is not equivalent to stating=20
>> requirements for acceptance.
>> =20
>> There may be other locally configured reasons to reject in addition to t=
hose=20
>> listed in the standard.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 23. On page 17, the text states:
>>> =20
>>> =20
>>> =20
>>>    3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
>>> =20
>>>    extension and is issued by the CA that issued the certificate in
>>> =20
>>>    question as stated above."
>>> =20
>>> =20
>>> =20
>>> In order to be crystal clear, it is proposed to change the wording in t=
he=20
>>> following way:
>>> =20
>>> =20
>>> =20
>>>    3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
>>> =20
>>>    extension and was signed by the CA using the same key that used=20
>>> =20
>>>    to issue the certificate in question.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> No, issuing with another key is not prohibited, and may be accepted by s=
ome=20
>> clients as an authorised responder.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 24. On page 17, the text states:
>>> =20
>>> =20
>>> =20
>>>    This SHOULD be a non-critical extension. The value of the extension=20
>>> =20
>>>    SHALL be NULL.
>>> =20
>>> =20
>>> =20
>>> The ASN.1 syntax is missing. Add:=20
>>> =20
>>> =20
>>> =20
>>>    NoCheck ::=3D NULL
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Moving this to a separate discussion.
>> =20
>> I'm not sure what the preferred way to describe this is.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 25. Remainder: On page 18, the general text from section 4.2.2.3 Basic=20
>>> Response is no more needed and=20
>>>  should be deleted. See comment 20.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 26. On page 24, text should be added to the Security consideration sect=
ion:
>>> =20
>>> =20
>>> =20
>>> Different  results when using OCSP and CRLs
>>> =20
>>> =20
>>> =20
>>>    OCSP clients or verifiers must build and verify a certification path=
=20
>>> =20
>>>    for each target certificate up to a trusted root.  When an OCSP=20
>>> =20
>>>    Responder is using published CRLs, it must also build and verify a=20
>>> =20
>>>    certification path for the CRLs it uses up to a trusted root.
>>> =20
>>> =20
>>> =20
>>>    However, it should be realized that the root used by an OCSP=20
>>> =20
>>>    Responder to verified these CRLs is not necessarily the same as the=20
>>> =20
>>>    one that would be used by the OCSP client, if it were going to verif=
y=20
>>> =20
>>>    the CRLs itself.  Hence the revocation status may not be identical=20
>>> =20
>>>    in both cases.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> I don't understand this one.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 27. On page 24, text should be added to the Security consideration sect=
ion:
>>> =20
>>> =20
>>> =20
>>> Denial  of service attack using a flood of queries
>>> =20
>>> =20
>>> =20
>>>    A denial of service vulnerability is evident with respect to a flood=
=20
>>> =20
>>>    of queries.  The production of a cryptographic signature=20
>>> =20
>>>    significantly affects response generation cycle time, thereby=20
>>> =20
>>>    exacerbating the situation.=20
>>> =20
>>> =20
>>> =20
>>>    The flood of queries may either come from a flood attack or from the=
=20
>>> =20
>>>    fact that there are too many certificates supported by the same OCSP=
=20
>>> =20
>>>    responder.  In the later case, the number of queries can be=20
>>> =20
>>>    reduced by using a technique similar to the splitting of CRLs:=20
>>> =20
>>> =20
>>> =20
>>>       When a block of certificates have been issued with the same=20
>>> =20
>>>       accessLocation in the AIA extension field of these certificates,=20
>>> =20
>>>       then the accessLocation should be changed.  In this way, a given=20
>>> =20
>>>       OCSP server will only be responsible for a block of certificates.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> If the security considerations section is talking about splitting OCSP=20
>> responders in this way, then the document itself need to introduce the=20
>> subject.
>> =20
>> I would suggest that it is beyond this update to do so.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 28. On page 31, the text states.
>>> =20
>>> =20
>>> =20
>>>    An alternative to this module that conforms to the 2002 version of=20
>>> =20
>>>    ASN.1 may be found in Section 4 of [RFC5912].=20
>>> =20
>>> =20
>>> =20
>>> RFC 5912 omits to define the nocheck extension. Thus it is inappropriat=
e to=20
>>> refer to RFC 5912.=20
>>> =20
>>> =20
>>> =20
>>> The corrected module should be defined in this new draft.=20
>>>  A corrected module is provided in draft-pinkas-rfc2560bis-03.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Will move this (as stated above) to a separate discussion.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 29. Different topics are not covered by the document. These topics are=20
>>> important.=20
>>>  The following comments propose text to be placed in annexes. Three ann=
exes=20
>>> are being proposed.
>>> =20
>>> =20
>>> =20
>>> Note: The texts are extracted from draft-pinkas-rfc2560bis-03.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>> Each such amendment need to be thoroughly reviewed and motivated.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 30. First annex being proposed. This annex is important, because key=20
>>> rollover is not addressed in the draft.
>>> =20
>>> =20
>>> =20
>>> KEY  ROLLOVER
>>> =20
>>> =20
>>> =20
>>> 1. CA that directly supports an OCSP service
>>> =20
>>> =20
>>> =20
>>>    When a CA that directly supports an OCSP service performs a key=20
>>> =20
>>>    rollover:
>>> =20
>>> =20
>>> =20
>>>    - for certificates issued under the old key, the CA SHALL continue=20
>>> =20
>>>      to sign the revocation status of OCSP responses with that old key=20
>>> =20
>>>      at least until all these certificates are expired, and
>>> =20
>>> =20
>>> =20
>>>    - for certificates issued under the new key, the CA SHALL change the=
=20
>>> =20
>>>      accessLocation in the AIA extension field of these certificates=20
>>> =20
>>>      and sign the revocation status of OCSP responses with that new key=
=20
>>> =20
>>>      at least until all these certificates are expired.
>>> =20
>>> =20
>>> =20
>>>    Note: The change in accessLocation is necessary when the CA rekeys=20
>>> =20
>>>          to meet the following constraints imposed by this standard:=20
>>> =20
>>> =20
>>> =20
>>>             1) a BasicOCSPResponse can only be signed using a single=20
>>> =20
>>>                private  key;=20
>>> =20
>>> =20
>>> =20
>>>             2) the response must be signed using the same CA key that=20
>>> =20
>>>                was used to sign the certificate in question; and
>>> =20
>>> =20
>>> =20
>>>             3) the OCSP response needs to cover all the certificates=20
>>> =20
>>>                queried in the OCSP request.
>>> =20
>>> =20
>>> =20
>>> 2. CA that uses OCSP responders
>>> =20
>>> =20
>>> =20
>>>    When a CA that uses OCSP Responders performs a key rollover, then=20
>>> =20
>>>    it MUST either designate a new OCSP Responder or keep the current=20
>>> =20
>>>    OCSP Responder(s).
>>> =20
>>> =20
>>> =20
>>>    If the CA designates a new OCSP Responder, then it SHALL change the=20
>>> =20
>>>    accessLocation in the AIA extension field for the newly issued=20
>>> =20
>>>    certificates and issue an OCSP certificate to the new OCSP Responder=
=20
>>> =20
>>>    using its new key.
>>> =20
>>> =20
>>> =20
>>>    If the CA keeps the same OCSP Responder(s), then it SHALL continue=20
>>> =20
>>>    to use the same accessLocation(s) in the AIA extension field for the=
=20
>>> =20
>>>    newly issued certificates and issue an OCSP certificate to the=20
>>> =20
>>>    appropriate OCSP Responder(s) using its new key.
>>> =20
>>> =20
>>> =20
>>>    Note: The CA may need to continue issuing certificates to the OCSP=20
>>> =20
>>>    Responder(s) using the old CA key until all the certificates issued=20
>>> =20
>>>    under the CA' old key for which the OCSP Responder(s) are=20
>>> =20
>>>    authoritative have expired.
>>> =20
>>> =20
>>> =20
>>> 3. OCSP Responder key rollover
>>> =20
>>> =20
>>> =20
>>>    When an OCSP Responder performs a key rollover (asynchronously from=20
>>> =20
>>>    a CA key rollover), then each CA which has designated an OCSP=20
>>> =20
>>>    Responder SHALL issue a new certificate for that OCSP Responder and=20
>>> =20
>>>    for each of its issuing keys which meets the following property:=20
>>> =20
>>> =20
>>> =20
>>>       - the issuing key has been used to sign at least one certificate=20
>>> =20
>>>         which contains an AIA extension designating that OCSP Responder=
=20
>>> =20
>>>         and that certificate is not yet expired.
>>> =20
>>> =20
>>> =20
>>>    An OCSP Responder key rollover does not affect the values of the=20
>>> =20
>>>    URIs that are placed in the accessLocation field from the target=20
>>> =20
>>>    certificates.  One or more OCSP Responder MAY respond to an OCSP=20
>>> =20
>>>    request addressed at a given URI picked from the accessLocation=20
>>> =20
>>>    field from a target certificate.  Each OCSP Responder MAY use a=20
>>> =20
>>>    different signing key, as long as it got an OCSP certificate=20
>>> =20
>>>    appropriate for that signing key and for the target certificate.=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 31. Second annex being proposed. This annex is important because it=20
>>> describes the validation of an OCSP response in the past=20
>>>  which is of a particular importance when validating electronic signatu=
res.
>>> =20
>>> =20
>>> =20
>>> Response  processing by an OCSP client
>>> =20
>>> =20
>>> =20
>>>    OCSP responses can be verified at the current time by an OCSP client=
=20
>>> =20
>>>    when receiving a response, whereas old responses can be verified at=20
>>> =20
>>>    a time in the past by a verifier.  The algorithm below addresses=20
>>> =20
>>>    both cases.
>>> =20
>>> =20
>>> =20
>>>    Prior to processing a basic response, OCSP clients MUST determine=20
>>> =20
>>>    the checking time, which may be either the current time or a time=20
>>> =20
>>>    in the past.
>>> =20
>>> =20
>>> =20
>>>    OCSP clients or verifiers SHALL check if the response contains=20
>>> =20
>>>    responseExtensions. If such an extension is found and is recognized,=
=20
>>> =20
>>>    it MUST be processed.  If such a critical extension is found and=20
>>> =20
>>>    is not recognized, the whole OCSP response MUST be considered as=20
>>> =20
>>>    invalid.
>>> =20
>>> =20
>>> =20
>>>    If the checking time is the current time, and if a nonce extension=20
>>> =20
>>>    has been used in the request and is recognized (see section 4.5.1),=20
>>> =20
>>>    OCSP clients MUST check whether the same nonce is present in the=20
>>> =20
>>>    response.  If the nonce is not present or is different, then the=20
>>> =20
>>>    OCSP response MUST be discarded.
>>> =20
>>> =20
>>> =20
>>>    Only the single response(s) which are/is of interest SHALL be=20
>>> =20
>>>    checked.
>>> =20
>>> =20
>>> =20
>>> STEP  1
>>> =20
>>> =20
>>> =20
>>>    OCSP clients or verifiers SHALL verify that the certificate=20
>>> =20
>>>    identified in a single response is of interest.  Otherwise, proceed=20
>>> =20
>>>    to step 3.
>>> =20
>>> =20
>>> =20
>>>    If the certificate status included in a single certificate response=20
>>> =20
>>>    is "unknown", then the revocation status of that certificate is=20
>>> =20
>>>    "unknown", and proceed to step 3.
>>> =20
>>> =20
>>> =20
>>>    If the certificate status from the single certificate response is=20
>>> =20
>>>    either "good" or "revoked", OCSP clients or verifiers SHALL check=20
>>> =20
>>>    that the checking time is within the validity period of the target=20
>>> =20
>>>    certificate.  If it is not the case, then the revocation status of=20
>>> =20
>>>    that certificate is "unknown" and proceed to step 3.
>>> =20
>>> =20
>>> =20
>>>    If the checking time is the current time, and if a nonce has been=20
>>> =20
>>>    used in the request, then proceed to step 2.
>>> =20
>>> =20
>>> =20
>>>    If the checking time is the current time, and if no nonce has been=20
>>> =20
>>>    used in the request, OCSP clients MUST check that the producedAt
>>> =20
>>>    field is within a time window that is "close enough" to the current=20
>>> =20
>>>    time.=20
>>> =20
>>> =20
>>> =20
>>>    Note: the notion of "close enough" is a local matter.  It can be set=
=20
>>> =20
>>>          to a few minutes to allow for small UTC time differences=20
>>> =20
>>>          between the client and the server or to a few hours in case=20
>>> =20
>>>          the server is producing pre-computed responses.
>>> =20
>>> =20
>>> =20
>>>    If the checking time is a time in the past, verifiers MUST check=20
>>> =20
>>>    that the producedAt field is in accordance with the verification=20
>>> =20
>>>    rules (e.g. close and/or after the date of a time-stamp token).
>>> =20
>>> =20
>>> =20
>>>    In addition, if the nextUpdate field is present, OCSP clients MUST=20
>>> =20
>>>    check that the time which is indicated is greater than the checking=20
>>> =20
>>>    time, otherwise the single response MUST be discarded.
>>> =20
>>> =20
>>> =20
>>>    If checks are successful, then OCSP clients MUST process the=20
>>> =20
>>>    singleExtensions  field, if it is present.=20
>>> =20
>>> =20
>>> =20
>>>    If the criticality flag is set and the extension is not understood,=20
>>> =20
>>>    then the status of the certificate shall be "unknown" and proceed to=
=20
>>> =20
>>>    step 3.  Otherwise, proceed to step 2.=20
>>> =20
>>> =20
>>> =20
>>>    If the extension is understood, then the extension MUST be=20
>>> =20
>>>    processed.  According to its content proceed either to step 2 or to=20
>>> =20
>>>    step 3.=20
>>> =20
>>> =20
>>> =20
>>> STEP  2
>>> =20
>>> =20
>>> =20
>>>    OCSP clients or verifiers MUST build and verify a certification path=
=20
>>> =20
>>>    for that certificate up to a trusted root, so that they have the=20
>>> =20
>>>    knowledge of the CA public key value that was used to sign the=20
>>> =20
>>>    target certificate.  The revocation status of each certificate of=20
>>> =20
>>>    that certification path (except the target certificate) SHALL be=20
>>> =20
>>>    checked.
>>> =20
>>> =20
>>> =20
>>>    If no path can be built or if one of the certificates of the path is=
=20
>>> =20
>>>    revoked, then the revocation status of that certificate is "unknown"=
,=20
>>> =20
>>>    and proceed to step 3.=20
>>> =20
>>> =20
>>> =20
>>>    If the certification path (except the target certificate) is valid,=20
>>> =20
>>>    then two cases need to be considered:
>>> =20
>>> =20
>>> =20
>>>    a) If the responderID matches with the name or the key from the CA=20
>>> =20
>>>       which has issued the target certificate, then check whether the=20
>>> =20
>>>       OCSP response is signed by the same key that was used to sign=20
>>> =20
>>>       the target certificate.
>>> =20
>>> =20
>>> =20
>>>              If it is the case, then the revocation status of that=20
>>> =20
>>>              certificate  as indicated in the certStatus field is=20
>>> =20
>>>              accepted and proceed to step 3.
>>> =20
>>> =20
>>> =20
>>>              If it is not the case, then the revocation status of that=20
>>> =20
>>>              certificate  is "unknown" and proceed to step 3.
>>> =20
>>> =20
>>> =20
>>>    b) If the responderID does not match with the name or the key from=20
>>> =20
>>>       the CA which has issued the target certificate, then it indicates=
=20
>>> =20
>>>       the name or the key from an OCSP Responder.  Check whether there=20
>>> =20
>>>       exists a local rule which applies to this target certificate to=20
>>> =20
>>>       verify that the signature of the BasicOCSPResponse is valid for=20
>>> =20
>>>       that single response.  If this rule exists, it SHALL be followed.=
=20
>>> =20
>>> =20
>>> =20
>>>       Otherwise check whether there is an OCSP certificate (i.e. which=20
>>> =20
>>>       has both the ocspSigning OID in the extended key usage extension=20
>>> =20
>>>       and the digitalSignature bit in the key usage extension) signed=20
>>> =20
>>>       by the same key that was used to sign the target certificate.=20
>>> =20
>>>       This certificate MUST be present in the certs field from the=20
>>> =20
>>>       BasicOCSPResponse. =20
>>> =20
>>> =20
>>> =20
>>>           If such certificate is not found or is invalid, then the=20
>>> =20
>>>           revocation  status of that certificate is "unknown" and=20
>>> =20
>>>           proceed to step 3.
>>> =20
>>> =20
>>> =20
>>>           If such certificate exists and if the checking time is=20
>>> =20
>>>           within the validity period of this certificate, then it MUST=20
>>> =20
>>>           be verified whether the OCSP response can be verified using=20
>>> =20
>>>           the public key that is present in the OCSP Certificate.=20
>>> =20
>>> =20
>>> =20
>>>              If it is not the case, then the revocation status of that=20
>>> =20
>>>              certificate  is "unknown" and proceed to step 3.
>>> =20
>>> =20
>>> =20
>>>              If it is the case, then it MUST be verified that the OCSP=20
>>> =20
>>>              Certificate  has not been revoked.
>>> =20
>>> =20
>>> =20
>>>      If one of these conditions is met, then the status for the target=20
>>> =20
>>>      certificate as indicated in the certStatus field is accepted,=20
>>> =20
>>>      otherwise the revocation status is "unknown".
>>> =20
>>> =20
>>> =20
>>> STEP  3
>>> =20
>>> =20
>>> =20
>>>    If there exists another single certificate status response for a=20
>>> =20
>>>    target certificate that is of interest, then proceed to step 1.=20
>>> =20
>>>    Otherwise the basic response is now processed.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 32. Third annex being proposed. This annex is important because it prov=
ides=20
>>> guidance on how to build an OCSP responder in the three cases.=20
>>>  Many text portions are similar, but three full texts are provided in o=
rder=20
>>> to provide a better clarity for each of the three cases.
>>> =20
>>> =20
>>> =20
>>> 1. Request processing by OCSP servers
>>> =20
>>> =20
>>> =20
>>>    The behavior of an OCSP server will be different whether the OCSP=20
>>> =20
>>>    server is a CA acting as an OCSP responder, is an OCSP Responder=20
>>> =20
>>>    which received a delegation from one or more CAs, or is a locally=20
>>> =20
>>>    trusted Responder.
>>> =20
>>> =20
>>> =20
>>> 1.1.  Processing by a CA acting as an OCSP responder
>>> =20
>>> =20
>>> =20
>>>    The OCSP responder SHALL maintain a list of entries. Each entry=20
>>> =20
>>>    SHALL contain:
>>> =20
>>> =20
>>> =20
>>>      - the URI associated to the OCSP responder, from which the OCSP=20
>>> =20
>>>        requests are received,=20
>>> =20
>>> =20
>>> =20
>>>      - the DN from a CA,
>>> =20
>>> =20
>>> =20
>>>      - an issuing public key from a CA,
>>> =20
>>> =20
>>> =20
>>>      - the method(s) used to know for which subset of certificates=20
>>> =20
>>>        issued by the CA it is responsible for,=20
>>> =20
>>> =20
>>> =20
>>>      - the method(s) used to obtain the revocation status of that=20
>>> =20
>>>        subset of certificates issued under that CA issuing public key,=20
>>> =20
>>>        and
>>> =20
>>> =20
>>> =20
>>>      - the method used to gain access and sign with the private key=20
>>> =20
>>>        corresponding to the issuing public key.
>>> =20
>>> =20
>>> =20
>>>    For a given URI value, the OCSP responder SHALL only use one CA=20
>>> =20
>>>    key pair value.=20
>>> =20
>>> =20
>>> =20
>>>    When it receives an OCSP request on that URI, the OCSP responder=20
>>> =20
>>>    SHALL handle exceptions according to section 2.3.=20
>>> =20
>>> =20
>>> =20
>>>    If the OCSP request contains the name of a requestor, the OCSP=20
>>> =20
>>>    responder SHALL verify whether there exists a locally defined rule=20
>>> =20
>>>    which regulates access control.  If this rule exists, it SHALL be=20
>>> =20
>>>    followed.
>>> =20
>>> =20
>>> =20
>>>    Then, for each target certificate, the OCSP responder SHALL verify=20
>>> =20
>>>    whether both the hash of the issuer's DN and the hash of the issuer=20
>>> =20
>>>    public key which are present in the request are eligible to a=20
>>> =20
>>>    locally defined rule which indicates that the OCSP responder is=20
>>> =20
>>>    responsible to provide the revocation status of that target=20
>>> =20
>>>    certificate.  If this rule exists, it SHALL be followed.
>>> =20
>>> =20
>>> =20
>>>    Otherwise, the OCSP responder SHALL determine whether it is=20
>>> =20
>>>    responsible to provide the revocation status of that target=20
>>> =20
>>>    certificate according to the following rule.
>>> =20
>>> =20
>>> =20
>>>    For each target certificate, the OCSP responder SHALL verify whether=
=20
>>> =20
>>>    both the hash of the issuer's DN and the hash of the issuer public=20
>>> =20
>>>    key which are present in the request match respectively with the DN=20
>>> =20
>>>    and the hash of the public key of contained in an entry from the=20
>>> =20
>>>    list of entries maintained by this OCSP responder.=20
>>> =20
>>> =20
>>> =20
>>>    When there is no match, then the OCSP responder SHALL indicate the=20
>>> =20
>>>    "unknown" status and proceed with the next target certificate from=20
>>> =20
>>>    the OCSP request.
>>> =20
>>> =20
>>> =20
>>>    When there is a match, then the OCSP responder SHALL use the serial=20
>>> =20
>>>    number of the target certificate that is present in the request and=20
>>> =20
>>>    determine the revocation status of that certificate according to=20
>>> =20
>>>    the method(s) defined in the entry.=20
>>> =20
>>> =20
>>> =20
>>>    When the revocation status is provided by the server using a real=20
>>> =20
>>>    time access to a database of revocation statuses of issued=20
>>> =20
>>>    certificates, then the thisUpdate field SHALL be present in the
>>> =20
>>>    SingleResponse  response whereas the nextUpdate field SHALL be=20
>>> =20
>>>    missing.=20
>>> =20
>>> =20
>>> =20
>>>    Otherwise, both the thisUpdate and the nextUpdate fields SHALL be=20
>>> =20
>>>    present in the SingleResponse.=20
>>> =20
>>> =20
>>> =20
>>>    The time at which this response will be signed MUST be indicated in=20
>>> =20
>>>    the producedAt field from the SingleResponse.
>>> =20
>>> =20
>>> =20
>>>    If a singleRequestExtensions is present in the request it MUST be=20
>>> =20
>>>    processed.
>>> =20
>>> =20
>>> =20
>>>    If there is another target certificate present in the request, it=20
>>> =20
>>>    SHALL be processed in the same way.
>>> =20
>>> =20
>>> =20
>>>    If a requestExtensions is present in the request it MUST be=20
>>> =20
>>>    processed.
>>> =20
>>> =20
>>> =20
>>>    The OCSP response MUST be signed using the CA issuing private key.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 1.2.  Processing by an OCSP Responder
>>> =20
>>> =20
>>> =20
>>>    For each CA from which the OCSP Responder has received a delegation,=
=20
>>> =20
>>>    the OCSP Responder SHALL maintain a list of entries.=20
>>> =20
>>> =20
>>> =20
>>>    Each entry SHALL contain:
>>> =20
>>> =20
>>> =20
>>>      - the URI associated to this OCSP Responder, from which the OCSP=20
>>> =20
>>>        requests are received,=20
>>> =20
>>> =20
>>> =20
>>>      - the DN from a CA,
>>> =20
>>> =20
>>> =20
>>>      - an issuing public key from a CA,
>>> =20
>>> =20
>>> =20
>>>      - the method(s) used to know for which subset of certificates=20
>>> =20
>>>        issued by the CA it is responsible for,=20
>>> =20
>>> =20
>>> =20
>>>      - the method(s) used to obtain the revocation status of that=20
>>> =20
>>>        subset of certificates issued under that CA issuing public key,
>>> =20
>>> =20
>>> =20
>>>      - an OCSP certificate,=20
>>> =20
>>> =20
>>> =20
>>>      - the OCSP public key contained in that OCSP certificate, and
>>> =20
>>> =20
>>> =20
>>>      - the method used to gain access and sign with the OCSP private=20
>>> =20
>>>        key corresponding to that OCSP certificate.
>>> =20
>>> =20
>>> =20
>>>    For a given URI value, the OCSP Responder SHALL only use one OCSP=20
>>> =20
>>>    key pair value.  Therefore there cannot be two entries with the=20
>>> =20
>>>    same URI value and a different OCSP public key value.
>>> =20
>>> =20
>>> =20
>>>    NOTE: a BasicOCSPResponse can only be signed using a single private=20
>>> =20
>>>          key.=20
>>> =20
>>> =20
>>> =20
>>>    The OCSP certificate SHALL be signed by the CA issuing private key=20
>>> =20
>>>    which corresponds to the issuing CA public key that is in this=20
>>> =20
>>>    entry.
>>> =20
>>> =20
>>> =20
>>>    When it receives an OCSP request, the OCSP responder SHALL handle=20
>>> =20
>>>    exceptions according to section 2.3.=20
>>> =20
>>> =20
>>> =20
>>>    If the OCSP request contains the name of a requestor, the OCSP=20
>>> =20
>>>    responder SHALL verify whether there exists a locally defined rule=20
>>> =20
>>>    which regulates access control.  If this rule exists, it SHALL be=20
>>> =20
>>>    followed.
>>> =20
>>> =20
>>> =20
>>>    For each target certificate, the OCSP Responder SHALL verify=20
>>> =20
>>>    whether both the hash of the issuer's DN and the hash of the issuer=20
>>> =20
>>>    public key which are present in the OCSP request match with those=20
>>> =20
>>>    from an entry.
>>> =20
>>> =20
>>> =20
>>>    When there is no match, then the OCSP Responder SHALL indicate the=20
>>> =20
>>>    "unknown" status and proceed with the next target certificate from=20
>>> =20
>>>    the OCSP request.
>>> =20
>>> =20
>>> =20
>>>    When there is a match, the OCSP Responder SHALL use the serial=20
>>> =20
>>>    number of the target certificate this is present in the OCSP=20
>>> =20
>>>    request to determine the revocation status of that certificate=20
>>> =20
>>>    according to the method(s) indicated in the entry.=20
>>> =20
>>> =20
>>> =20
>>>    When the revocation status is provided by the server using a real=20
>>> =20
>>>    time access to a database of revocation statuses of issued=20
>>> =20
>>>    certificates, then the thisUpdate field SHALL be present in the
>>> =20
>>>    SingleResponse  response whereas the nextUpdate field SHALL be=20
>>> =20
>>>    missing.=20
>>> =20
>>> =20
>>> =20
>>>    Otherwise, both the thisUpdate and the nextUpdate fields SHALL be=20
>>> =20
>>>    present in the SingleResponse.=20
>>> =20
>>> =20
>>> =20
>>>    The time at which this response will be signed MUST be indicated in=20
>>> =20
>>>    the producedAt field from the SingleResponse.
>>> =20
>>> =20
>>> =20
>>>    If a singleRequestExtensions is present in the request it MUST be=20
>>> =20
>>>    processed.
>>> =20
>>> =20
>>> =20
>>>    If there is another target certificate present in the request, it=20
>>> =20
>>>    SHALL be processed in the same way.
>>> =20
>>> =20
>>> =20
>>>    If a requestExtensions is present in the request it SHALL be=20
>>> =20
>>>    processed.
>>> =20
>>> =20
>>> =20
>>>    The OCSP response MUST be signed using the OCSP private key.
>>> =20
>>> =20
>>> =20
>>>    Unless there is a local rule which states differently, for every=20
>>> =20
>>>    target certificate which matches both with the hash of a CA DN and a=
n=20
>>> =20
>>>    issuing public key from an entry, the OCSP certificate of that entry=
=20
>>> =20
>>>    SHALL be placed in the certs field.
>>> =20
>>> =20
>>> =20
>>>    It may happen, that none of the target certificates from the OCSP
>>> =20
>>>    request matches both with the hash of a CA DN and an issuing public=20
>>> =20
>>>    key from an entry.  In that case and unless a local rule states=20
>>> =20
>>>    differently, the certs field from the BasicOCSPResponse SHOULD be=20
>>> =20
>>>    kept empty (to limit the disclose of the names of the CAs from which=
=20
>>> =20
>>>    the OCSP Responder received a delegation from).
>>> =20
>>> =20
>>> =20
>>> 1.3.  Processing by a locally trusted Responder
>>> =20
>>> =20
>>> =20
>>>    For each CA for which the locally trusted Responder is=20
>>> =20
>>>    authoritative, the OCSP Responder SHALL maintain a list of entries.=20
>>> =20
>>> =20
>>> =20
>>>    Each entry SHALL contain:
>>> =20
>>> =20
>>> =20
>>>      - the URI associated to this OCSP Responder, from which the OCSP=20
>>> =20
>>>        requests are received,=20
>>> =20
>>> =20
>>> =20
>>>      - the DN from a CA,
>>> =20
>>> =20
>>> =20
>>>      - an issuing public key from a CA,
>>> =20
>>> =20
>>> =20
>>>      - the method(s) used to know for which subset of certificates=20
>>> =20
>>>        issued by the CA it is responsible for,=20
>>> =20
>>> =20
>>> =20
>>>      - the method(s) used to obtain the revocation status of that=20
>>> =20
>>>        subset of certificates issued under that CA issuing public key,
>>> =20
>>> =20
>>> =20
>>>      - the method used to gain access to the private key in order to=20
>>> =20
>>>        sign the OCSP response.=20
>>> =20
>>> =20
>>> =20
>>>    For a given URI value, the OCSP Responder SHALL only use one private=
=20
>>> =20
>>>    key.  Therefore there cannot be two entries with the same URI value=20
>>> =20
>>>    and a different method to gain access to the appropriate private key=
.
>>> =20
>>> =20
>>> =20
>>>    NOTE: a BasicOCSPResponse can only be signed using a single private=20
>>> =20
>>>          key.=20
>>> =20
>>> =20
>>> =20
>>>    When it receives an OCSP request, the OCSP responder SHALL handle=20
>>> =20
>>>    exceptions according to section 2.3.=20
>>> =20
>>> =20
>>> =20
>>>    If the OCSP request contains the name of a requestor, the OCSP=20
>>> =20
>>>    responder SHALL verify whether there exists a locally defined rule=20
>>> =20
>>>    which regulates access control.  If this rule exists, it SHALL be=20
>>> =20
>>>    followed.
>>> =20
>>> =20
>>> =20
>>>    For each target certificate, the OCSP Responder SHALL verify=20
>>> =20
>>>    whether both the hash of the issuer's DN and the hash of the issuer=20
>>> =20
>>>    public key which are present in the OCSP request match with those=20
>>> =20
>>>    from an entry.
>>> =20
>>> =20
>>> =20
>>>    When there is no match, then the OCSP Responder SHALL indicate the=20
>>> =20
>>>    "unknown" status and proceed with the next target certificate from=20
>>> =20
>>>    the OCSP request.
>>> =20
>>> =20
>>> =20
>>>    When there is a match, the OCSP Responder SHALL use the serial=20
>>> =20
>>>    number of the target certificate this is present in the OCSP=20
>>> =20
>>>    request to determine the revocation status of that certificate=20
>>> =20
>>>    according to the method(s) indicated in the entry.=20
>>> =20
>>> =20
>>> =20
>>>    When the revocation status is provided by the server using a real=20
>>> =20
>>>    time access to a database of revocation statuses of issued=20
>>> =20
>>>    certificates, then the thisUpdate field SHALL be present in the
>>> =20
>>>    SingleResponse  response whereas the nextUpdate field SHALL be=20
>>> =20
>>>    missing.=20
>>> =20
>>> =20
>>> =20
>>>    Otherwise, both the thisUpdate and the nextUpdate fields SHALL be=20
>>> =20
>>>    present in the SingleResponse.=20
>>> =20
>>> =20
>>> =20
>>>    The time at which this response will be signed MUST be indicated in=20
>>> =20
>>>    the producedAt field from the SingleResponse.
>>> =20
>>> =20
>>> =20
>>>    If a singleRequestExtensions is present in the request it MUST be=20
>>> =20
>>>    processed.
>>> =20
>>> =20
>>> =20
>>>    If there is another target certificate present in the request, it=20
>>> =20
>>>    SHALL be processed in the same way.
>>> =20
>>> =20
>>> =20
>>>    If a requestExtensions is present in the request it SHALL be=20
>>> =20
>>>    processed.
>>> =20
>>> =20
>>> =20
>>>    The OCSP response MUST be signed using the OCSP private key.
>>> =20
>>> =20
>>> =20
>>>    The certs field may contain no, one or several OCSP certificates=20
>>> =20
>>>    according to local rules followed by the locally trusted Responder.
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>> =20
>> /Stefan
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> End of comments
>>> =20
>>> =20
>>>=20
>>>  Denis
>>> =20
>>> =20
>>> =20
>>>  =20
>>> =20
>>>  _______________________________________________ pkix mailing list=20
>>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix=20
>>  =20
> =20
> =20
> _______________________________________________ pkix mailing list=20
> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix=20



--B_3443590283_11353265
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


Denis,

<=
div>I will review your comments.
Unfortunately I won't be able to =
do so this week.

This document has already been sen=
t to the IESG with a request for publication.
I will check in what=
 way the comments will be handled.

/Stefan

From:  Denis Pinkas <denis.pinkas@bull.net>
Date:  Monday, February 11, 2013 3:18 PM
To:  Stefan Santesson <stefan@aaa-sec.com>
Cc:  pkix <pkix@ietf.org&=
gt;
Subject:  Re: [pkix] Review of =
2560-bis draft 8. Answer to WGLC


  
    
  
  

    

        
        
Stefan,

        
 

        
I have
            finally reviewed your disposition of comments. I have used
            draft 13.

        
 

        
I will
            not <=
span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB">address the comments in sequence, but
            I will consider four categories:

        
 

        
Category 1) Some comments which
            seem to be solved. Yes indeed, they may be a
            few of them !

        
 

        
Category 2) Some comments which
            might possibly be solved at the WG level.
=

        
 

        
Category 3) Some comments that
            I will address at the IETF last call
            level, rather than the WG last call level, since I disagree
            

            that it is “new
            ways to say the same thing” and it is likely to be a wast=
e
            of time for both of
            us to argue again at the WG level 

            (these comments are commented as “not
            broken”).

        
 

        
Category 4) Some typos and
            editorials found while reading
            draft 13.

        
 

        
 

        
CATEGORY 1=


        
 

        
Comment 4 (was
            editorial).

        
 

        
Comment 5.=


        
 
=

        
Comment 6. 

        
 

        
Comment 19. Solved, since
          “unknown” seems now to be also allowed for
            non-issued certificates 

            (even if the
            OCSP responder is using a direct access to the certificate
            database). See
            comment 8.

        
 

        
Comment 13: Acceptable,
            since the text uses “MAY=
221;.

        
 

        
Comment 18. 

        
 

        
Comment 22.

        
 

        
Comment 23.

        
 

        
Comment 28.

        
 

        
CATEGORY 1=


        
 

        
Comment 8: You have
            changed the meaning of the revoked
            state in a way that is not what I requested. =


        
 

        
The
            original text was:

        
 

        
   The
              "revoked" state indicates that the certificate has been
              revoked

        
  
              (either permanantly or temporarily (on hold)).

        
 

        
The new
            text is:

        
 
=

        
   The =
"revoked" state indicates that the certificate has been revoked

        
   eith=
er permanently or temporarily on hold (i.e. the revocation reason=


        
   is c=
ertificateHold).

        
 

        
By doing
            this, you do not allow any other case in the future to have
            a temporary
            revocation: “temporarily
on
              hold”=
 

            is not the same as “temporarily
              revoked”.

        
 

        
I propose
            the following rewording: 

        
 

        
   The
              "revoked" state indicates that the certificate has been
              revoked 

        
   eith=
er permanently or temporarily (e.g. placed on hold).
        
 

        
The way the
            text from draft 13 is now written seems to allow using
            either “unknow=
n” or “revoked” for non-issued certificates. 

            If this is the intent, then the good news
            is that this does not come anymore into conflict with the
            French rules which
            apply for 

            the Administration since OCSP responders from CAs used by
            the French
            Ministries having a direct access to the database 

            of issued certificates will
            be able to use “unknow=
n”, rath=
er than
          “revoke=
d” and t=
he reason
            code “onhold=
”.<=
/o:p>

        
 

        
However,
            the current text is still mandating the use of Extended Revoked
              Definition, but the rational for its need it
            is very poor. 

            As I have said on the PKIX list, the fact that the
            revocation
            date is January 1rst, 1970 is fully sufficient to know that
            we are in that 

            very
            special case, and you have not provided a rational to say
            the contrary.

        
 

        
So we could
            get rid of it, … but the text from section 4.4.8 states:<=
o:p>

        
 

        
   This=
 extension MAY be present in other responses to signal that the

        
   resp=
onder implements the extended revoked definition in section 2.2.<=
/span>

        
 

        
I have
            difficulties to understand what is really meant there
            (“other responses” ?),
            since the text states:

        
 

        
   This=
 extension indicates that the responder supports the extended

        
   defi=
nition of the "revoked" status to also include non-issued<=
/b>

        
   cert=
ificates according to section 2.2.

        
 

        
Since both
            “unknown” and revoked” can be used, it would =
be desirable to
            be able to include
            the same extension in both cases, 

            but in that case that extension should be
            renamed.

        
 

        
I would
            propose to rename it: "non-issued certificate” which means that the associated CA =
has
            no record of ever having issued
            

            a certificate with the certificate serial number in the
            request (I still
            consider it as unnecessary in the case of “revoked”=
, but it
            would be 

            very
            useful in the case of “unknown”). Of course, the te=
xt from
            section 4.4.8 would
            need to be revised.

        
 

        
I propose
            the following:

        
 

        
4.4.8  Non-i=
ssued certificate extension

        
 

        
   This extension MUST be included in the OC=
SP response when the OCSP 

        
   responder knows that the CA identified in the request has no record 

        
   of ever having issued a certificate with the certificate serial =


        
   number indicated in the request.

        
 

        
   Clients do not have to parse this extensi=
on in order to determine 

        
   the status of certificates in responses.

        
 

        
   This extension is identified by the objec=
t identifier id-pkix-ocsp-

        
   non-=
issued-cert.

        
 

        
     id-pkix-ocsp-non-issued-cert =
OBJECT IDENTIFIER ::=3D {id-pkix-ocsp 9}

        
 

        
   The value of the extension SHALL be NULL.=
 This extension MUST NOT be

        
   mark=
ed critical.

        
 

        
Then the
            text on page 8 would need to be rearranged.
        
 

        
The current
            text is:

        
 

        
   This=
 state MAY also be returned if the

        
   asso=
ciated CA has no record of ever having issued a certificate with<=
/span>

        
   the =
certificate serial number in the request, using any current or

        
   prev=
ious issuing key (referred to as a "non-issued" certificate in

        
   this=
 document).

        
 

        
   The "unknown" state indicates that the re=
sponder doesn't know about

        
   the =
certificate being requested.

        
 

        
   NOTE: The "revoked" state for known non-i=
ssued certificate serial

        
    =
     numbers is allowed in order to reduce the ri=
sk of relying

        
    =
     parties using CRLs as a fall back mechanism,=
 which would be

        
    =
     considerably higher if an "unknown" response=
 was returned.

        
 

        
   When a responder responds revoked to a st=
atus request for a non-

        
   issu=
ed certificate, the responder MUST include the extended revoked

        
   defi=
nition response extension (section 4.4.8) in the response,=


        
   indi=
cating that the OCSP responder supports the extended definition

        
   of r=
evoked state to also cover non-issued certificates. In addition,<=
/span>

        
   the =
SingleResponse related to this non-issued certificate;=


        
 

        
    - MUST provide the revocation reaso=
n certificateHold (6),

        
 

        
    - MUST specify the revocationTime J=
anuary 1, 1970, and;

        
 

        
    - MUST NOT include a CRL References extension (section 4.4.2) or any=


        
    =
  CRL Entry Extensions (section 4.4.5). 
        
 

        
Proposed
            text for a replacement:

        
 

        
   The =
"unknown" state indicates that the responder doesn't know about

        
   the =
certificate being requested.

        
 

        
   If the OCSP responder knows that CA ident=
ified in the request has 

        
   no record of ever having issued a certificate with the certificate 

        
   serial number in the request, using any current or previous issuing 

        
   key (referred to as a "non-issued" certificate in this document), 

        
   the OCSP responder SHALL respond either “revoked “ or “un=
known”.

        
 

        
   Note: The "revoked" state for known non-i=
ssued certificate serial 

        
   numbers is allowed in order to reduce the risk of relying parties 

        
   using CRLs as a fall back mechanism, which would be possible when 

        
   the "unknown" response is returned.

        
 

        
   When a responder responds revoked or unkn=
own to a status request 

        
   for a non-issued certificate, the responder MUST include the 

        
   non-issued certificate extension (see section 4.4.8) in the 

        
   response. 

        
 

        
   When a responder responds revoked to a st=
atus request for a non-

        
   issu=
ed certificate, in addition, the responder:

        
 

        
    - MUST provide the revocation reaso=
n certificateHold (6),

        
 

        
    - MUST specify the revocationTime J=
anuary 1, 1970, and;

        
 

        
    - MUST NOT include a CRL References=
 extension (section 4.4.2) or any

        
    =
  CRL Entry Extensions (section 4.4.5).
        
 

        
Finally,
            the last bullet on page 4 should be reworded:=


        
 

        
Current
            text:

        
 

        
    =
  o Section 4.4.8 specifies a new extension that indicates that =
the

        
    =
     responder supports the extended use of the "=
revoked" response

        
    =
     for non-issued certificates defined in secti=
on 2.2.

        
 
=

        
Proposed
            replacement text:

        
 

        
    =
  o  Section 4.4.8 sp=
ecifies a new extension that indicates that 

        
    =
     the OCSP responder knows that CA identi=
fied in the request 

        
    =
     has no record of ever having issued a c=
ertificate with the 

        
    =
     certificate serial number present in th=
e request, as defined 

        
    =
     in section 2.2.
        
 

        
Comment 9: Solved, if the
            comment above may be solved.

        
 

        
Comment 20:&nbs=
p; This
            comment is preliminary classified by you as “not broken&#=
8221;.
            However, since you
            asked: “If you don’t replace 4.2.2.3,

            then what really are you missing ?”, I
            will provide you with an answer.

        
 

        
This is the
            wrong way to state the question. Providing an ASN.1 syntax
            as in 4.2.1 is not
            enough: the use of every parameter 

            MUST be explained using English words. So if
            you explain the use of every parameter after the description
            of the ASN.1
            syntax 

            in section 4.2.1. then section 4.2.2.3 is no more needed and
            thus can be
            deleted.

        
 

        
The answer
            to your question “what is really missing” is a desc=
ription
            of the use of every
            parameter listed in the ASN.1 in section 4.2.1

        
 

        
Comment 21.

        
 

        
While I can
            agree in general with the intent of the text, I do not
            understand the first
            sentence of the Note which speaks of “CA key rolloverR=
21; 

            and is copied below:

        
 

        
   Note=
: CA key rollover is not prohibited when issuing a certificate

        
    =
     for an authorized responder for backwards co=
mpatibility with

        
    =
     RFC 2560 [RFC2560]. That is, it is not prohi=
bited to issue a

        
    =
     certificate for an authorized responder usin=
g a different

        
    =
     issuing key than the key used to issued the =
certificate being

        
    =
     checked for revocation. However, such practi=
ce is strongly

        
    =
     discouraged since clients are not required t=
o recognize a

        
    =
     responder with such certificate as an author=
ized responder.

        
 

        
I would
            propose to delete it, since it does not add anything and
            thus to have:

        
 

        
   Note=
: For backwards compatibility with RFC 2560 [RFC2560], it is 

        
    =
     not prohibited to issue a certificate f=
or an authorized 

        
    =
     responder using a different issuing key=
 than the key used to 

        
    =
     issued the certificate being checked fo=
r revocation. 

        
    =
     However, such practice is strongly disc=
ouraged since clients 

        
    =
     are not required to recognize a respond=
er with such 

        
    =
     certificate as an authorized responder.=


        
 

        
Comment 24: The ASN.1
            module in annex B.1 is still wrong,
            since it does not define NoCheck. 

        
 

        
Comment 26: You asked for
            explanations. Let me provide
            you with an example when CRLs are being used by the OCSP
            responder 

            in the
            background. The OCSP responder needs to make sure that the
            CRL it uses is
            valid. If it is simply using published CRLs 

            (i.e. no trusted link with the CA),
            it needs to make sure that the CA which has issued the CRL
            has no been revoked.

        
 

        
In France,
            there is a root CA for the Administration. However, the use
            of that root CA is
            optional. Thus a Ministry may have its own root, 

            but may also have its key
            certified by the root CA of the Administration. The OCSP
            responder may use the
            root CA of the Ministry, 

            while a relying party may use the root CA of the
            Administration (or the reverse) to validate the CRL for the
            target certificate.
            

            Thus the revocation status will be different if the
            certificate of the CA of
            the Ministry is revoked by the root CA of the
            Administration.

        
 

        
CATEGORY 3=


        
 

        
Comments 2, 3, 7, 10,
            12, 14, 15, 16, 17, 25 and 27.

        
 

        
 

        
CATEGORY 4=


        
 

        
Page 4. The
            indentation of the bullets in section 1 is not uniform. 

            Bullets 1, 4, 5 and 9 have problems.

        
 

        
Page 4. The
            fact that there is now an Annex B.2 dealing with the 2008
            ASN.1 syntax is
            missing. This should be added.

        
 

        
Page 10.
            Change “Se
              further section 4.2.2.2” into “See
              further section 4.2.2.2”

            

        


          Denis

          

        
 

        
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
              

            

      

    

    
=

      
Denis,

      


      

      
Responding to your
        comments below.

      


      

      
However, one
        general remark to make recurring comments easier to understand.
      


      

      
The WG decided to
        adopt a minimalistic approach to updating RFC 2560. That means
        that 

      
    
        
  1. We don't change anything from RFC 2560 unless it is broken,
          or the industry clearly need clarifications in order to avoid
          interoperability issues.
    2. 
        
  2. We retain the document structure of RFC 2560 as much as
          possible to allow easy comparison of what the changes are in
          comparison with RFC 2560.
    3. 
      

      


      

      
One can always
        think up more clever ways to write things out in words. But that
        also comes with a risk.

      
The current words
        has been around for a long time and we know from experience
        which words worked to produce working implementations, and which
        did not.

      
Introducing new
        ways to say the same thing may introduce new problems and people
        might disagree on what the new perfect wording should be. And
        this could go on forever.

      


      

      
So when my reply
        is "Not broken", then that is because the current wording does
        not have such problems that is merits a change.

      


      

      


      

      


      

      
        
From:  Denis Pinkas <denis.pinkas@bull.net>

          Date:  Sunday, January
          20, 2013 5:12 PM

          To:  Stefan Santesson
          <st=
efan@aaa-sec.com>,
          Stephen Kent <kent@bbn.com>

          Cc:  pkix <pkix@ietf.org>

          Subject:  Re: [pkix]
          Review of 2560-bis draft 8. Answer to WGLC

        

        


        

        

          

            
            
 
 
  Normal
  0
  21
  
  
  false
  false
  false
  
   
   
   
   
   
  
  MicrosoftInternetExplorer4
 

                
                
Please find 32 comments on draft-ietf-pkix-rfc2560bis

                
 

                
1. The
                    document states:

                
&n=
bsp;<Cut away issue 1 regarding authorship
                    etc, as it has been responded to separately><=
/p>
              

          

        

      
      


      

      
Responded to
        separately.

      


      

      
        

          

            

                

                
 

                
 

                
2. The
                    current text from section 2 states:
                
 

                
2.<=
span style=3D"mso-spacerun:yes">  Protocol Overview

                
 

                
   In lieu of or as a supplemen=
t to checking against a periodic CRL, it

                
   may be necessary to obtain <=
b style=3D"mso-bidi-font-weight:normal">timely information regarding the

                
   revocation status of a certi=
ficate (cf. RFC5280], Section 3.3).

                
   Examples include high-value =
funds transfer or large stock trades.

                
 

                
   The Online Certificate Statu=
s Protocol (OCSP) enables applications to

                
   determine the (revocation) s=
tate of an identified certificate. OCSP

                
   may be used to satisfy some =
of the operational requirements of

                
   providing more timely revocation information than is possible=
 with

                
   CRLs and may also be used to=
 obtain additional status information. 

                
 

                
This text is misleading because readers may think tha=
t OCPS necessarily provides “timely information”.

                
 

              

          

        

      
      


      

      
"may" does not
        mean "necessarily".

      


      

      
        

          

            

                
Proposed text replacement:

                
 

                
   The Online
                      Certificate Status Protocol (OCSP) is a
                      client-server 

                
   protocol
                      which enables applications to obtain the
                      revocation status 

                
   of one or
                      more certificates either "good", "revoked", or
                      "unknown".

                
=
 

                
   The
                      revocation status may be provided by the server
                      either using a 

                
   real time
                      access to a database of issued certificates, or
                      using a 

                
   batch access
                      to a database of issued certificates, or using a 

                
   real time
                      access to a database of revocation statuses of
                      issued 

                
   certificates,
                      or using a batch access to a database of
                      revocation 

                
   statuses of
                      issued certificates, or using CRLs, or using a <=
/o:p>

                
   combination
                      of base CRLs and delta CRLs.
                
=
 

                
   In the first
                      case, it is possible to obtain timely revocation
                      status 

                
   information,
                      whereas in the other cases, the freshness of the 

                
   revocation
                      status is not better than the mechanisms it is
                      based on.

                
 

                
 

              

          

        

      
      


      

      
Not broken

      


      

      
        

          

            

                
3. The
                    current text from section 2 states:
                
 

                
   An OCSP client issues a stat=
us request to an OCSP responder and 

                
   Suspends acceptance of =
the certificate in question until=
 the 

                
   responder provides a re=
sponse.

                
 

                
   This protocol specifies the =
data that needs to be exchanged between

                
   an application checking the =
status of a certificate and the server

                
   providing that status.<=
/o:p>

                
 

                
Thus is insufficient for an overview. More details ar=
e needed to know what the document provides, 
in particular that the request may contain several requests for several cer=
tificates issued by different CAs. 
The possibility of using extensions should also be advertised.

                
 

                
Proposed text replacement:

                
 

                
 &nbs=
p; When using
                    OCSP, an OCSP client issues a certificate revocation
                    

                
 &nbs=
p; status request
                    to an OCSP responder for one or
                      more certificates 

                
   issued by
                      the same CA or for one or more certificates issued
                      by 

                
   different
                      CAs and
                    then suspends acceptance of the certificate(s) 

                
 &nbs=
p; in question
                    until the responder provides a response.

                
 

                
 &nbs=
p; This document
                    specifies the data that needs to be exchanged
                    between

                
 &nbs=
p; an application
                    checking the status of a certificate and the server

                
 &nbs=
p; providing that
                    status.  

                
 

                
   OCSP may
                      also provide additional status information using 

                
   extensions.
                      

                
 

                
 

              

          

        

      
      


      

      
Not broken

      


      

      
        

          

            

                
4. Page
                    6. Editorial. Punctuation and a CR/LF are missing.=


                
 

                
The
                    text states:

                
 

                
   3. t=
he request contains the information needed by the responder If

                
    =
  any one of the prior conditions are not met, the OCSP responde=
r

                
    =
  produces an error message; otherwise, it returns a definitive<=
o:p>

                
    =
  response.

                
 

                
It
                    should state:

                
 

                
   4. t=
he request contains the information needed by the responder.

                
 

                
      If any one of the prior=
 conditions are not met, the OCSP responder

                
    =
  produces an error message; otherwise, it returns a definitive<=
o:p>

                
    =
  response.

                
 

                
 

              

          

        

      
      


      

      
Fixed in draft 10.
      


      

      
        

          

            

                
5. On
                    page 7, the text states:

                
&n=
bsp;

                
   All
                      definitive response messages SHALL be digitally
                      signed. The key

                
   used to sign
                      the response MUST belong to one of the following:

                
 

                
   -  the CA who issued the certificate in question
                
   -  a Trusted Responder whose public k=
ey is trusted by the requester

                
   -  a CA Designated Responder (Authori=
zed Responder) who holds a

                
    =
  specially marked certificate issued directly by the CA, indica=
ting

                
    =
  that the responder may issue OCSP responses for that CA.<=
/o:p>

                
&n=
bsp;

                
The
                    paragraph is ambiguous on several aspects. <=
/span>

                
 

                
Delegation

                    is addressed in at least three different places, but
                    with different terms and conditions. 

                    If some one picks a sentence in one paragraph rather
                    than another, it will lead to a different
                    conclusion. 

                    RFCs are supposed to be clear.

                
 

                
On
                    page 10, the current text states in section 2.6 OCSP
                      Signature Authority Delegation stat=
es:<=
/o:p>

                
 

                
   The
                        key that signs a certificate's status
                        information need not be the

                
   same

                      key that signed the certificate. A
                      certificate's issuer

                
   explicitly
                      delegates OCSP signing authority by issuing a
                      certificate

                
   containing a
                      unique value for extendedKeyUsage in the OCSP
                      signer's

                
   certificate.
                      This certificate MUST be issued directly to the<=
/o:p>

                
   responder by
                      the cognizant CA.

                
 

                
On page
                    16, there is a section 4.2.2=
.2 called “Auth=
orized
                      Responders”
                    dealing with the same topic. 

                
 

                
Section
                    4.2.2.2 states:

                
 

                
   The
                        key that signs a certificate's status
                        information need not be the

                
   same

                      key that signed the certificate. It
                      is necessary however to

                
   ensure that
                      the entity signing this information is authorized
                      to do

                
   so.  Therefore, a
                      certificate's issuer MAY either sign the OCSP

                
   responses
                      itself or it MAY explicitly designate this
                      authority to

                
   another
                      entity.  O=
CSP

                      signing delegation SHALL be designated by the

                
   inclusion of
                      id-kp-OCSPSigning in an extendedKeyUsage
                      certificate

                
   extension
                      included in the OCSP response signer's
                      certificate.  This

                
   certificate
                      MUST be issued directly by the CA that issued the

                
   certificate
                      in question.

                
 

                
   The CA
                      SHOULD use the same issuing key to issue a
                      delegation

                
   certificate
                      as was used to sign the certificate being checked
                      for

                
   revocation.
                      =
Systems

                        relying on OCSP responses MUST recognize a

                
   delegat=
ion

                      certificate as being issued by the CA that issued
                      the

                
   certifi=
cate

                      in question only if the delegation certificate and
                      the

                
   certifi=
cate

                      being checked for revocation was signed by the
                      same key.<=
/b>

                
 

                
The
                    last sentence above in yellow is the key sentence
                    that is missing in the two other sections.

                
 

                
Most implementations only support the case where the =
OCSP Responder receives an OCSP certificate that is signed by the same key 
that was used to sign the target certificate. They do not support the case =
where the OCSP Responder receives an OCSP certificate 
that is signed by a key that is different from the one that was used to sig=
n the target certificate.

                
 

                
It is
                    inappropriate to have three sections dealing with
                    the same topic with a slightly different meaning.<=
/o:p>

                
 

                
It is
                    proposed the following.

                
 

                
On page
                    7, after:

                
 

                
   -  a CA Designated Responder (Authori=
zed Responder) who holds a

                
    =
  specially marked certificate issued directly by the CA, indica=
ting

                
    =
  that the responder may issue OCSP responses for that CA.<=
/o:p>

                
 

                
it is
                    proposed to add “(see
                      section 4.2.2.2 for further details)=
221;, so
                    that the reader knows that more details are provided
                    later on.

                
 

                
Then
                    we do not need two sections to address delegation
                    which start with the same sentence: 

                  

                


                    “The key t=
hat
                      signs a certificate's status information need not
                      be the same key that signed the certificate”.

                
 

                
It is
                    thus proposed to delete section 2.6.<=
/p>
                
 

                
Section
                    4.2.2.2 will thus remain the single section
                    providing full details.

                
 

                
 

              

          

        

      
      


      

      
I have added
        references to section 4.2.2.2 in the quoted sections in 2.2 and
        2.6.

      
(will be included
        in draft 11)

      


      

      


      

      
        

          

            

                
=
6. Page=
 7, the text states:

                
 

                
   A de=
finitive response message is composed of:

                
 

                
   -  version of the response syntax

                
   -  name of the responder

                
   -  responses for each of the certific=
ates in a request

                
   -  optional extensions

                
   -  signature algorithm OID=


                
   -  signature computed across hash of =
the response

                
 

                
This
                    description does not fit with the ASN.1 syntax which
                    is detailed later on, and in particular:

                
 

                
   ResponseData ::=3D SEQUENCE {

                
      version          =
    [0] EXPLICIT Version DEFAULT v1,
                
      responderID  &=
nbsp;           Res=
ponderID,

                
    =
  producedAt   &nb=
sp;           Gener=
alizedTime,

                
    =
  responses   &nbs=
p;            =
SEQUENCE OF SingleResponse,

                
    =
  responseExtensions   =
[1] EXPLICIT Extensions OPTIONAL }

                
 

                
Proposed text replacement:

                
 

                
   A definitive
                      response message is composed of:

                
=
 

                
   - a response
                      status and if there is no error, the following:<=
/o:p>

                
   - the
                      version of the response syntax,=


                
   - an
                      identifier of the OCSP server,<=
/p>
                
   - the time
                      at which the response was produced,=


                
   - single
                      responses for each of the target certificates,

                
   - optional
                      extensions,

                
   - the
                      signature algorithm OID,

                
   - the
                      signature computed across hash of the response,
                      and

                
   - optional
                      certificates.

                
 

                
 

              

          

        

      
      


      

      
This is an
        overview section. We ought not try to duplicate the level of
        detail provided in the detailed protocol section.

      
A "definitive
        response" according to tho 2.1 is a response to an error-free
        request, so your first remark is redundant.

      


      

      
I have added a
        note about time to the current list, and changed "name" to
        identifier in bullet 2. 

      
(will be included
        in draft 11)

      


      

      
        

          

            

                
7. The
                    text states on page 7:

                
 

                
   The response
                      for each of the certificates in a request consists
                      of

                
 

                
   -  =
target
                      certificate identifier

                
   -  =
certificate
                      status value

                
   -  =
response
                      validity interval

                
   -  =
optional
                      extensions

                
 

                
However,

                    there are no explanations for the purpose of these
                    parameters and how they should be processed.=


                
There
                    are also no explanations on how to process a single
                    response and how to verify that it is its presence
                    within the signed structure 

                    is valid or not valid. This is a major deficiency of
                    the current description of RC 2560 where there is no
                    explanation on how to validate 

                    a single response.

                
 

                
Text
                    proposal to be added after:

                
 

                
   The purpose
                      of the identifier of the OCSP server is to allow
                      OCSP 

                
   clients to
                      find whether the definitive response was signed by
                      a CA 

                
   or by an
                      OCSP Responder.

                
=
 

                
   The
                      identifier of the OCSP server SHOULD either be the
                      name or the 

                
   key from a
                      CA, or the name or the key from a OCSP Responder.

                
=
 

                
   Unless there
                      exist local rules (which are outside the scope of
                      this 

                
   document)
                      for verifying that a single response is correctly
                      signed, 

                
   the
                      following applies:

                
 

                
   When the
                      identifier matches with the name of the CA which
                      has issued 

                
   the target
                      certificate or corresponds to the key used to
                      issue the 

                
   target
                      certificate, then a single response is correctly
                      signed 

                
   only if the
                      digital signature of the OCSP response is valid
                      using the 

                
   key used to
                      sign the target certificate.
                
=
 

                
   When the
                      identifier does not match with the name of the CA
                      which has 

                
   issued the
                      target certificate or does not correspond to the
                      key used 

                
   to issue the
                      target certificate, then an single response is
                      correctly 

                
   signed only
                      if :

                
=
 

                
         <=
/span>(a)
                      there exists in the response an OCSP certificate
                      issued by 

                
        &n=
bsp;    the
                      CA which has issued the target certificate which
                      is 

                
        &n=
bsp;    signed
                      by the same key as the one used to issue the 

                
        &n=
bsp;    target

                      certificate, and

                
=
 

                
         <=
/span>(b)
                      the digital signature of the OCSP response is
                      valid using 

                
        &n=
bsp;    the

                      subjectPublicKey contained in this OCSP
                      certificate.

                
 

                
 

              

          

        

      
      


      

      
Not broken.

      
All of this is
        already covered by the document.

      


      

      
        

          

            

                
8. The
                    text states on page 7:

                
 

                
   The "revo=
ked"
                    state indicates that the certificate has been
                    revoked

                
   (either
                      permanently or temporarily (on hold)). This
                    state MAY also be

                
   returned =
if
                    the responder knows that the requested certificate
                    has

                
   never been
                      issued during the history of the associated CA us=
ing

                    any

                
   current o=
r
                    previous issuing key. 

                
 

                
The
                    text is ambiguous because there are two embedded
                    parenthesis and it is unclear whether the inner
                    parenthesis means “i.e” or “e.g”=
;. 

                    This single sentence may let think that on hold is
                    the single case for temporarily revocation. Since
                    neither X.509 nor RFC 5280 address 

                    the case of a temporary revocation in the context of
                    an OCSP response (but only in the context of CRLs),
                    we are able to add another case 

                    of temporary revocation which will only apply in the
                    context of OCSP.

                
 

                
The
                    above sentence using the terms “neve=
r
                      been issued during the history of the associated
                      CA “does
                    not capture the fact 

                    that it could be issued in the future, hence why
                    using “not yet been used”<=
/b> would
                    be more appropriate.

                
 

                
Finally,
                    it would have been more logical to use “unknown&#=
8221;. So
                    it is important to add a note to explain why we have
                    chosen that case for “legacy clients”, 
=

                    otherwise the people who have not participate to the
                    exchanges will not understand.

                
 

                
Proposed text replacement:

                
 

                
   The "revoked" state indicates that the certificate has been revok=
ed,

                
   eith=
er permanently or temporarily.

                
 

                
   A certificate may be tempora=
rily revoked either because it is 

                
   placed on hold (i.e. the revocation reason is certificateHol=
d) or 

                
   because the responder i=
s able to know, using a positive list of 

                
   issued certificates, th=
at the serial number from the requested 

                
   certificate has not yet been used by the CA to issue a c=
ertificate 

                
   (i.e. the revocation reason is notIssuedOrIrregularlyIssued<=
/b>).

                
 

                
NOTE: The "revoked" state is used rather than the ̶=
0;unknown” state, to

                
    =
  make sure that relying parties that were conformant to RFC 256=
0

                
    =
  will not use CRLs as a fall back mechanism. =


                
 

              

          

        

      
      


      

      
I removed the
        double parenthesis and adopted your clarification with regard to
        "on hold". 

      


      

      
The text in draft
        10 has changed from what you have commented on. I believe that
        text is better.

      


      

      
You "Note" has
        problems.

      
    
        
  1. We do not prevent responders to respond "unknown" if their
          assessment is that this is an appropriate response,
          considering what they know about the requested serial number.
          Thus the term "is used" is misleading.
    2. 
        
  2. This mechanisms does not "make sure" that the clients do
          anything. It's up to the discretion of the relying party to
          decide what source of revocation checking they rely on. This
          does however reduce the risk of clients falling back to CRL:s
        
  3. This mechanism is not just relevant to old clients, but also
          to new one for the same reason.
    4. 
      

      


      

      
I have adopted a
        modified version of your Note:

      


      

      

        
   NOTE: The "revoked" stat=
e for
            known non-issued certificate serial

        
         num=
bers is allowed in
            order to reduce the risk of relying

        
         par=
ties using CRLs as a
            fall back mechanism, which would be

        
         con=
siderably higher if an
            "unknown" response was returned.

      

      


      

      


      

      


      

      
        

          

            

                
 

                
9. The
                    text states on page 8:

                
 

                
   When a
                      responder responds revoked to a status request for
                      a non-

                
   issued
                      certificate, the responder MUST also;

                
 

                
    - include
                      the extended revoked definition response extension

                
      (section
                      4.8), indicating that the OCSP responder supports
                      the

                
      extended
                      definition of revoked state to also cover
                      non-issued

                
      certificates,

                
 

                
    - provide
                      the revocation reason certificateHold (6), and;<=
/o:p>

                
 

                
    - specify
                      the revocation date January 1, 1970. 

                
 

                
As
                    already explained on the PKIX list, using the
                    revocation reason certificateHold is not appropriate 

                    because it changes the meaning of certificateHold. 

                
 

                
The
                    extended revoked definition response extension is a
                    means to signal that it not a true certificate hold
                    but a “not issued certificate”. 

                    Legacy applications cannot take advantage of it. <=
/o:p>

                
 

                
Some
                    applications which handle non repudiation enter a
                    waiting state when the revocation reason
                    certificateHold is used thus 

                    it is not appropriate to overload the meaning.

                
 =


                
It is
                    possible to use another enumeration for signalling
                    that specific case:

                
notIssuedOrIrregularlyIssued

                    (7).

                
 =


                
Thus
                    for new applications it would be much better to use
                    notIssuedOrIrregularlyIssued (7) as already proposed
                    on the PKIX list.

                
 

                
The above sentence uses the text: 
                
 

                
=
220;a status request for a non-issued=
 certificate” 

                
 

                
whereas it would be more appropriate to state:=
 

                
 

                
=
220;a status request for a serial num=
ber which has not been used by the CA or used irregularly to issue a certifi=
cate”.

                
 

                
Placing the ASN.1 description at such a place in the =
document is inappropriate since the ASN.1 structures have not yet been descr=
ibed. 
Thus only the functional aspects should be mentioned, but not the ASN.1 imp=
lications.

                
 

                
BTW, the description should follow the same order as =
the ASN.1. This is not the case. 

                
 

                
This text should be deleted from this section and the=
 appropriate text should be added when the parameters of the response are de=
scribed. 

                
 

                
The text proposed in the previous comment should be s=
ufficient at this time of reading.

                
 

                
In
                    addition, section
                      4.4.8  Ext=
ended

                      Revoked Definition should be deleted.

                
 

                
 

              

          

        

      
      


      

      
The referred text has been updates in draft 09.

      


      

      
This has been discussed on the list and you have yet to
        convince the list of your new reason code.

      
I disagree as the risk of running into problems with the
        deployed base of application is hugely larger with introduction
        of a new reason code, rather than using certificateHold.

      
No application should be broken, since no application have
        business asking for non-issued cert serial numbers in the first
        place. Secondly, no application can assume that a
        certificateHold reason will be cleared any time soon.

      


      

      


      

      
        

          

            

                
10. The
                    text states on page 8:

                
 

                
2.4  Semantics of
                      thisUpdate, nextUpdate and producedAt

                
 

                
This
                    section is misplaced. At this time of reading, the
                    reader does not know that thisUpdate, nextUpdate and
                    producedAt are values 

                    used by the ASN.1 structures. It is appropriate to
                    describe what theses parameters mean when the ASN.1
                    syntax is described. 

                    The current ASN.1 syntax is very badly described.
                    One would expect that after every ASN.1 structure
                    description every parameter is described. 

                    Unfortunately this is not the case. 

                    

                
The
                    text from this section is not aligned with the text
                    that is present in section 4.2.2.1. 
                
 

                
In
                    particular, in section 2.4:

                
 

                
   If
                      nextUpdate is not set, the responder is indicating
                      that newer

                
   revocation
                      information is available all the time.

                
 

                
While
                    in section 4.2.2.1:

                
 

                
   Responses
                      where the nextUpdate value is not set are
                      equivalent 

                
   to a CRL
                      with no time for nextUpdate (see Section 2.4).

                
 

                
It is
                    not appropriate to have two different descriptions
                    in two different places.

                
 

                
Delete
                    section 2.4. See comment number 19 for the
                    description of these parameters.

              

          

        

      
      


      

      
Not broken.

      
The current text segments fits well into a protocol overview
        section.

      


      

      
        

          

            

                
 

                
 

                
11.
                    Section 2.5 is also misplaced. They use values from
                    the ASN.1 syntax which has not yet been described. 
=

                    They should be moved or incorporated in the document
                    once the ASN.1 description has been done.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
 

                
12.
                    Remainder: Section 2.6 should be deleted (see
                    comment number 5).

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
 

                
13.
                    Section 2.7 states:

                
 

                
2.7  CA Key
                      Compromise

                
 

                
   If an OCSP
                      responder knows that a particular CA's private key
                      has

                
   been
                      compromised, it MAY return the revoked state for
                      all

                
   certificates
                      issued by that CA.

                
 

                
This
                    section is misleading and should be removed. The
                    reason is the following:

                
 

                
The
                    relying party must verify that the singleResponse is
                    signed by a responder which is entitled to do so.<=
/o:p>

                
 

                
a) If
                    the CA key has been compromised and if the response
                    is signed by that CA key then the singleResponse
                    will be discarded 

                    when performing the certification path validation wh=
atever
                      the content of the response may be.

                
 

                
b) If
                    the CA key which has issued the OCSP certificate has
                    been compromised and if the response is signed by
                    the key present 

                    in the OCSP certificate then the singleResponse will
                    be discarded when performing the certification path
                    validation

                    whatever the content of the response may be.

                
 

                
 

                
Security

                    must be provided using the validation of the
                    certification path. Thus it does not matter what the
                    OCSP responder states.

              

          

        

      
      


      

      


      

      
Not broken.

      
An OCSP responder does not have to be chained to the broken
        CA. The relying party may have other trust configuration at
        choice.

      


      

      


      

      
        

          

            

                


                

                
 

                
14. The
                    text states on page 11:

                
 

                
3.2  Signed
                      Response Acceptance Requirements

                
 

                
   Prior to
                      accepting a signed response as valid, OCSP clients
                      SHALL

                
   confirm
                      that:

                
 

                
   1. The
                      certificate identified in a received response
                      corresponds to

                
      that
                      which was identified in the corresponding request;

                
 

                
   2. The
                      signature on the response is valid;=


                
 

                
   3. The
                      identity of the signer matches the intended
                      recipient of the

                
      request.

                
 

                
   4. The
                      signer is currently authorized to sign the
                      response.

                
 

                
   5. The time
                      at which the status being indicated is known to be

                
      correct
                      (thisUpdate) is sufficiently recent.

                
 

                
   6. When
                      available, the time at or before which newer
                      information will

                
      be
                      available about the status of the certificate
                      (nextUpdate) is

                
      greater
                      than the current time.

                
 

                
This
                    section is misplaced since it uses terms from the
                    ASN.1 syntax and the protocol description has not
                    yet been made, 

                    since it is the next section 4. Its text is not
                    correct either. 

                
 

                
This
                    description does not take into account the fact that
                    a BasicOCSPResponse may
                    contain one or several SingleResponses. 

                    In particular, the sentence “The signer is currently
                      authorized to sign the response” is
                    misleading because a signer 

                    may be authorized to include some SingleResponses but not
                    necessarily all of them. 

                
 

                
The
                    appropriate explanations should be done after the
                    description of the response, when describing the
                    processing of the response.

                
 

                
Delete
                    that section.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
 

                
15. On
                    page 12, after the ASN.1 description, the only
                    parameters which are described are: <=
/p>
                
hashAlgorithm,=
 issuerNameHash,

                      issuerKeyHash and serialNumber.=


                
 

                
This
                    is insufficient.  <=
/span>In
                    order to cover the full list of parameters, the
                    following text is proposed:

                
 

                
   requestorName
                      is optional and MAY be used by the server for
                      access 

                
   control and
                      audit purposes.

                
=
 

                
   requestList
                      contains one or more single requests.

                
=
 

                
   requestExtensions
                      is OPTIONAL.  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.

                
=
 

                
   reqCert
                      contains the identifier of a target certificate.=


                
=
 

                
   issuerNameHash
                      is the hash of the Issuer's distinguished name.  The 

                
   hash shall
                      be calculated over the DER encoding of the
                      issuer's name 

                
   field in the
                      certificate being checked. 
=

                
=
 

                
   issuerKeyHash
                      is the hash of the Issuer's public key.  The hash 

                
   shall be
                      calculated over the value (excluding tag and
                      length) of the 

                
   subject
                      public key field in the issuer's certificate.  The hash 

                
   algorithm
                      used for both these hashes, is identified in 

                
   hashAlgorithm.
                      

                
=
 

                
     &nb=
sp;The primary
                      reason to use the hash of the CA's public key in 

                
      addition
                      to the hash of the CA's name, to identify the
                      issuer, 

                
      is that
                      it is possible that two CAs may choose to use the
                      same 

                
      name
                      (uniqueness in the Name is a recommendation that
                      cannot be 

                
      enforced).

                      Two CAs will never, however, have the same public
                      key 

                
      unless
                      the CAs either explicitly decided to share their
                      private 

                
      key, or
                      the key of one of the CAs was compromised.=


                
=
 

                
   serialNumber
                      is the serial number of the certificate for which
                      

                
   status is
                      being requested.

                
=
 

                
   singleRequestExtensions

                      is OPTIONAL.  Any

                      specific extension is 

                
   OPTIONAL.  The critical
                      flag SHOULD NOT be set for any of them. 

                
=
 

                
   The
                      requestor MAY choose to sign the OCSP request.  In that case,
                      the

                
   signature is
                      computed over the tbsRequest structure.  If the
                      request

                
   is signed,
                      the requestor SHALL specify its name in the
                      requestorName

                
   field.  Also, for
                      signed requests, the requestor MAY include=


                
   certificates
                      that help the OCSP responder verify the
                      requestor's

                
   signature in
                      the certs field of Signature.
                
 

              

          

        

      
      


      

      
Not broken.

      
The current text is short, but it is actually sufficient from
        the context of the ASN.1 definitions of the section. This is a
        detailed protocol section and the reader need to understand
        ASN.1 in any case to understand and implement the section.

      
The information about criticality is already covered in the
        extension section.

      


      

      


      

      
        

          

            

                
 

                
16.
                    Section 4.1.2 is called: “N=
otes on the
                      Request Syntax”

                
 

                
The
                    first paragraph has been moved after the description
                    of issuerKeyHash and
                    thus is no more needed.

                
 

                
The
                    second paragraph has been moved after the
                    description of requestExtensions. 

                    However, the sentence 

                    “ =
Unrecognized extensions MUST
                      be ignored (unless they have the critical flag set
                      and are not understood)” 

                    has been deleted since it applies to the OCSP
                    responder and not to the OCSP client. Thus it is no
                    more needed.

                
 

                
The
                    third paragraph applies to signed requests. However,
                    it should belong to a section dedicated on how
                    clients should build OCPS requests, 

                    which is currently missing. See the next comment.<=
/o:p>

                
 

                
This
                    section should be deleted.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
 

                
17. There
                    should be a new section called: “Requi=
rements

                      for OCSP clients”. 

                
 

                
It is
                    important first to re-advertise that the request may
                    be about several certificates. 

                    Thus it is important to describe the process for
                    building a request, which is currently missing.

                
 

                
   An OCSP
                      request allows getting in the same response the
                      revocation 

                
   status of
                      one or more certificates.  In order to
                      request the 

                
   status of
                      one or more certificates in a single request, OCSP
                      

                
   clients
                      SHALL follow the following rules :<=
/b>

                
=
 

                
   For each
                      candidate certificate, OCSP clients SHALL verify 

                
   whether
                      there exists a locally defined rule for the
                      certificate in 

                
   question
                      which indicates the URI where the OCSP responder
                      is 

                
   located.  If this rule
                      exists, it SHALL be followed. <=
/p>
                
=
 

                
   Otherwise,
                      OCSP clients SHALL determine whether the candidate
                      

                
   certificate
                      contains an AIA extension with an accessMethod
                      which 

                
   contains the
                      id-ad-ocsp OID.  =
If

                      it is the case, the accessLocation =


                
   contains a
                      uniformResourceIdentifier (URI) which indicates
                      the 

                
   location of
                      the OCSP server for that certificate. 

                
=
 

                
   Certificates
                      that contain the same URI MAY be grouped in a
                      single 

                
   request.=


                
=
 

                
Note:=
  For each
                      candidate certificate, when performing the path =


                
       valida=
tion

                      algorithm, the OCSP client SHOULD verify that the
                      

                
       curren=
t
                      time is within the validity period of the target 

                
       certif=
icate.  Certificates
                      which are outside their validity 

                
       period=

                      SHOULD NOT be included in the request.

                
 

                
   The
                      requestor MAY choose to sign the OCSP request. In
                      that case, the

                
   signature is
                      computed over the tbsRequest structure. If the
                      request

                
   is signed,
                      the requestor SHALL specify its name in the
                      requestorName

                
   field. Also,
                      for signed requests, the requestor MAY include

                
   certificates
                      that help the OCSP responder verify the
                      requestor's

                
   signature in
                      the certs field of Signature.
                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
Your text may provide guidance that could be useful to some
        implementers, but is completely beyond this document and
        further, not generally applicable or true.

      
As an example, an organisation may setup an in house locally
        configured OCSP responder that responds to all certificates "out
        there" that is relevant to that organisation.

      
Such clients would just blindly send OCSP requests to their
        local responder, disregarding any information in the cert.

      
It's totally beyond this spec to have an opinion about this.
      


      

      


      

      
        

          

            

                
 

                
18. The
                    text states on page 14:

                
 

                
   The
                      responder MAY include certificates in the<=
/span>

                
   certs field
                      of BasicOCSPResponse that help the OCSP client
                      verify the

                
   responder's
                      signature. If no certificates are included then
                      certs

                
   SHOULD be
                      absent.

                
 

                
While
                    this sentence is true, it is not sufficient. In
                    order to allow verifying every SingleResponse, 

                    it is important to include the relevant certificates
                    which are pertinent to every Sing=
leResponse.

                
 

                
Proposed

                    full text replacement:

                
 

                
   The respo=
nder
                    MAY include certificates in the certs field of 

                
   BasicOCSP=
Response

                    that help the OCSP client verify the responder's <=
/o:p>

                
   signature=
.

                
 

                
   For every
                      SingleResponse where the responder is not a CA,
                      the 

                
   responder
                      SHALL include the relevant OCSP certificate in the
                      certs 

                
   field of
                      BasicOCSPResponse in order to allow the OCSP
                      client 

                
   verifying
                      the responder was entitled to include that
                      SingleResponse 

                
   in the
                      signed BasicOCSPResponse.

                
=
 

                
   If
                    no certificates are included then certs SHOULD be
                    absent.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
This requirement would break backwards compatibility with RFC
        2560.

      
Further this would not be needed for a locally configured
        responder.

      


      

      
        

          

            

                
 

                
19. Page
                    15. The ASN.1 syntax should be changed in order to
                    be able to use the enumeration case 7 that is not
                    used for CRLs. 

                    This leads to the following change:
                
 

                
Current
                    text:

                
 

                
       revocationReason    [0]     EXPLICIT
                      CRLReason OPTIONAL }

                
 

                
Proposed

                    text change:

                
 

                
Revoc=
ationReason
::=3D

                      ENUMERATED {

                
        =
unspecified     &nbs=
p;       =
;      &=
nbsp;(0),

                
        =
keyCompromise     &n=
bsp;      &nb=
sp;     (1),

                
        =
cACompromise     &nb=
sp;      &nbs=
p;      =
(2),

                
        =
affiliationChanged    <=
span style=3D"mso-spacerun:yes">         (3),

                
        =
superseded      =
;       =
        (4),

                
        =
cessationOfOperation           (5),

                
        =
certificateHold     =
       &=
nbsp;   (6),

                
        =
notIssuedOrIrregularlyIssued

                        (7)=
,

                
        =
removeFromCRL     &n=
bsp;      &nb=
sp;     (8),

                
        =
privilegeWithdrawn           &nbs=
p; (9),

                
        =
aACompromise     &nb=
sp;      &nbs=
p;     (10) }

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
You have to convince the list about your new reason code.

      


      

      
        

          

            

                
 

                
20.
                    Page 15. After the ASN.1 syntax, there is no
                    description of every parameter, neither on its use 
=

                    (except a few words in section 4.=
2.2.1 Time
                    about=
 thisUpdate,
                      nextUpdate and producedAt).
=

                
 

                
Every
                    parameter needs to be described and explained.

                
 

                
   responderID
                      indicates either the name or the key from a CA, or
                      the 

                
   name or the
                      key from a OCSP Responder.

                
=
 

                
   producedAt
                      indicates the time at which this response was
                      signed.

                
=
 

                
   responses
                      contains one or more single responses.

                
=
 

                
   responseExtensions
                      is OPTIONAL.  Any

                      specific extension is OPTIONAL.=


                
   The critical
                      flag may or may not be set.
=

                
=
 

                
   certID is
                      usually a copy of the same field which was placed
                      in the 

                
   request, but
                      for OCSP responders which pre-produce signed
                      responses 

                
   certID may
                      be the identifier of a target certificate that was
                      not 

                
   present in
                      the request (see the end of section 4.2).<=
/span>

                
=
 

                
   certStatus
                      indicates the status of the certificate: either
                      good, 

                
   revoked or
                      unknown.

                
=
 

                
   thisUpdate
                      indicates the time at which the status being
                      indicated 

                
   is known to
                      be correct.

                
=
 

                
   nextUpdate
                      indicates the time at or before which newer
                      information 

                
   will be
                      available about the status of the certificate.  If 

                
   nextUpdate
                      is not set, the server is indicating that newer =


                
   revocation
                      information is available all the time. 

                
=
 

                
   If
                      nextUpdate is set, it often corresponds to the
                      {thisUpdate, 

                
   nextUpdate}
                      interval in CRLs. =
;
                      Responses whose nextUpdate value is 

                
   earlier than
                      the local UTC time value SHOULD be considered 

                
   unreliable.  Responses
                      whose thisUpdate time is later than the local 

                
   UTC time
                      SHOULD be considered unreliable.

                
=
 

                
   singleExtensions
                      is OPTIONAL.  Any

                      specific extension is OPTIONAL.=


                
   The critical
                      flag SHOULD NOT be set for any of them.

                
=
 

                
   revocationTime

                      indicates the time at which the certificate was =


                
   revoked.=


                
=
 

                
   revocationReason
                      is OPTIONAL.  It

                      includes all the cases that are 

                
   present in
                      CRLReason used for CRLs and an additional case 7
                      which is

                
   not used for
                      CRLs.  Cas=
e
                      7 is called notIssuedOrIrregularlyIssued. =


                
=
 

                
      -
                      "notIssued" corresponds to the case where the
                      certificate 

                
         <=
/span>serial
                      number that was sent was erroneous and has not yet
                      

                
         <=
/span>been
                      used by the CA at the time of the query,

                
=
 

                
      -
                      "irregularlyIssued" corresponds to the case where
                      the 

                
         <=
/span>certificate

                      serial number that was sent really exists in a <=
/o:p>

                
         <=
/span>certificate
                      that is correctly signed, but to its knowledge <=
/o:p>

                
         <=
/span>the CA
                      has not issued a certificate with such a serial =


                
         <=
/span>number.
                       As an
                      example, it may have been issued by the CA 

                
         <=
/span>because
                      the RA was compromised. 

                
=
 

                
   When=
 a responder responds revoked to a status request for which it 

                
   knows that the serial number has not been used by the CA or has =


                
   been irregularly used irregularly to issue a certificate, then <=
/span>

                
   in RevokedInfo the responder MUST:

                
 

                
      - specify the revocationTime :=
  January 1, 1970,

                
     =
; - provide the revocation=
Reason: notIssuedOrIrregularlyIssued (7).

                
 

                
   and in SingleResponse the responder MUST =
NOT include the nextUpdate.

                
=
 

                
   The response
                      MUST include a SingleResponse for each certificate
                      in

                
   the request
                      and SHOULD NOT include any additional
                      SingleResponse

                
   elements.  However,
                      there is one exception: 

                
 

                
      OCSP
                      responders MAY pre-produce signed responses
                      specifying the 

                
      status of
                      certificates at a specified time.  The time at
                      which 

                
      the
                      status was known to be correct SHALL be reflected
                      in the 

                
      thisUpdate
                      field of the response. 

                
=
 

                
      OCSP
                      responders that pre-generate status responses MAY
                      return 

                
      responses
                      that include additional SingleResponse elements if

                
      necessary
                      to improve response pre-generation performance or
                      cache

                
      efficiency
                      (as permitted in [RFC5019]).
                
 

                
Since
                    the text above provides all the explanations at the
                    level of the ASN.1 parameters, the general text 

                    from section
                      4.2.2.3 Basic Response is
                    no more need and should be deleted.

                
 

              

          

        

      
      


      

      
Preliminary I would say "not broken".

      
If you don't replace 4.2.2.3, then what really are you
        missing?

      


      

      
        

          

            

                
 

                
21. 0n
                    page 16, there is a section 4=
.2.2.2 called “Authorized Responders”

                
 

                
Section
                    4.2.2.2 states:

                
 

                
   (…)

                
   This
                      certificate MUST be issued directly by the CA that
                      issued the

                
   certificate
                      in question.

                
 

                
   The CA
                      SHOULD use the same issuing key to issue a
                      delegation

                
   certificate
                      as was used to sign the certificate being checked
                      for

                
   revocation.
                      Systems relying on OCSP responses MUST recognize a

                
   delegation
                      certificate as being issued by the CA that issued
                      the

                
   certificate
                      in question only if the delegation certificate and
                      the

                
   certificate
                      being checked for revocation was signed by the
                      same key.

                
 

                
This
                    section would need to reformatted to address CA
                    requirements first and then OCSP responder
                    requirements:

                
 

                
   (…)

                
   This
                      certificate MUST be issued directly by the CA that
                      issued the

                
   certificate
                      in question.  The
                      CA SHOULD use the same issuing key to 

                
   issue a
                      delegation certificate as was used to sign the
                      certificate 

                
   being
                      checked for revocation. 

                
 

                
   Systems
                      relying on OCSP responses MUST be able to
                      recognize a 

                
   delegation
                      certificate as being issued by the CA that issued
                      the 

                
   certificate
                      in question if the delegation certificate and 

                
   the
                      certificate being checked were signed by
                      the same key.

                
 

              

          

        

      
      


      

      
I disagree. The CA is actually free to do anything, but
        cannot expect the client to recognise the responder as
        authorised unless the same private key is used.

      
The current text places the requirement where they belong.
=

      


      

      
        

          

            

                
 

                
22. On
                    page 17, the text states:

                
 

                
   They MUST
                      reject the

                
   response if
                      the certificate required to validate the signature
                      on the

                
   response
                      fails to meet at least one of the following
                      criteria:

                
 

                
This
                    is ambiguous. It is inappropriate to have a negative
                    statement like “They MUST
                      reject”. 

                    The sentence should be turned in the positive form “They
                      SHALL accept” 

                
 

                
Since
                    the ASN.1 syntax has now be described, it is
                    possible to be more specific.

                
 

                
The
                    first occurrence of the word “response” sho=
uld be
                    changed into “singleResponse”, while the se=
cond
                    occurrence 

                    of the word “response” should be changed in=
to
                    “ResponseData”

                
 

                
Proposed

                    text replacement:

                
 

                
   They SHALL
                      accept a singleResponse if the certificate
                      required to 

                
   validate the
                      signature placed on the ResponseData meets one of
                      the 

                
   following
                      criteria:

              

          

        

      
      


      

      


      

      
No, this change is not backwards compatible.

      
So state the requirements for rejection is not equivalent to
        stating requirements for acceptance.

      
There may be other locally configured reasons to reject in
        addition to those listed in the standard.

      


      

      


      

      
        

          

            

                
 

                
 

                
23. On
                    page 17, the text states:

                
 

                
   3. Includes
                      a value of id-kp-OCSPSigning in an
                      ExtendedKeyUsage

                
   extension
                      and is issued by the CA that issued the
                      certificate in

                
   question as
                      stated above."

                
 

                
In
                    order to be crystal clear, it is proposed to change
                    the wording in the following way:
=

                
 

                
   3. Includes
                      a value of id-kp-OCSPSigning in an
                      ExtendedKeyUsage

                
   extension
                      and was signed by the CA using the same key that
                      used 

                
   to issue the
                      certificate in question.

                
 

              

          

        

      
      


      

      
No, issuing with another key is not prohibited, and may be
        accepted by some clients as an authorised responder.

      


      

      
        

          

            

                
 

                
24. On
                    page 17, the text states:

                
 

                
   This SHOULD
                      be a non-critical extension. The value of the
                      extension 

                
   SHALL be
                      NULL.

                
 

                
The
                    ASN.1 syntax is missing. Add: 

                
 

                
   NoCheck ::=3D
                      NULL

                
 

                
 

              

          

        

      
      


      

      
Moving this to a separate discussion.

      
I'm not sure what the preferred way to describe this is.

      


      

      


      

      
        

          

            

                
25.
                    Remainder: On page 18, the general text from section 4.2.2.3 Basic Response is no
                    more needed and 

                    should be deleted. See comment 20.
                
&n=
bsp;

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
26. On
                    page 24, text should be added to the Security
                    consideration section:

                
 

                
Diffe=
rent

                      results when using OCSP and CRLs

                
=
 

                
   OCSP clients
                      or verifiers must build and verify a certification
                      path 

                
   for each
                      target certificate up to a trusted root.  When an OCSP
                      

                
   Responder is
                      using published CRLs, it must also build and
                      verify a 

                
   certification
                      path for the CRLs it uses up to a trusted root.<=
/o:p>

                
=
 

                
   However, it
                      should be realized that the root used by an OCSP 

                
   Responder to
                      verified these CRLs is not necessarily the same as
                      the 

                
   one that
                      would be used by the OCSP client, if it were going
                      to verify 

                
   the CRLs
                      itself.  H=
ence
                      the revocation status may not be identical 

                
   in both
                      cases.

                
=
 

                
=
 

              

          

        

      
      


      

      
I don't understand this one.

      


      

      
        

          

            

                
27. On
                    page 24, text should be added to the Security
                    consideration section:

                
=
 

                
Denia=
l

                      of service attack using a flood of queries=


                
=
 

                
   A denial of
                      service vulnerability is evident with respect to a
                      flood 

                
   of queries.  The
                      production of a cryptographic signature 

                
   significantly
                      affects response generation cycle time, thereby =


                
   exacerbating
                      the situation. 

                
=
 

                
   The flood of
                      queries may either come from a flood attack or
                      from the 

                
   fact that
                      there are too many certificates supported by the
                      same OCSP 

                
   responder.  In the later
                      case, the number of queries can be =


                
   reduced by
                      using a technique similar to the splitting of
                      CRLs: 

                
=
 

                
      When a
                      block of certificates have been issued with the
                      same 

                
      accessLocati=
on
                      in the AIA extension field of these certificates,
                      

                
      then the
                      accessLocation should be changed.  In this way,
                      a given 

                
      OCSP
                      server will only be responsible for a block of
                      certificates.

                
=
 

              

          

        

      
      


      

      
If the security considerations section is talking about
        splitting OCSP responders in this way, then the document itself
        need to introduce the subject.

      
I would suggest that it is beyond this update to do so.

      


      

      
        

          

            

                
=
 

                
28. On
                    page 31, the text states.

                
 

                
   An
                      alternative to this module that conforms to the
                      2002 version of 

                
   ASN.1 may be
                      found in Section 4 of [RFC5912]. 

                
 

                
RFC
                    5912 omits to define the nocheck extension. Thus it
                    is inappropriate to refer to RFC 5912. 

                
 

                
The
                    corrected module should be defined in this new
                    draft. 

                    A corrected module is provided in draf=
t-pinkas-rfc2560bis-03.

                
 

              

          

        

      
      


      

      
Will move this (as stated above) to a separate discussion.
=

      


      

      
        

          

            

                
 

                
29.
                    Different topics are not covered by the document.
                    These topics are important. 

                    The following comments propose text to be placed in
                    annexes. Three annexes are being proposed.

                
 

                
Note:
                    The texts are extracted from draf=
t-pinkas-rfc2560bis-03.

                
 

                
 

              

          

        

      
      


      

      
Not broken.

      
Each such amendment need to be thoroughly reviewed and
        motivated.

      


      

      


      

      
        

          

            

                
30. First
                    annex being proposed. This annex is important,
                    because key rollover is not addressed in the draft.

                
 

                
KEY

                      ROLLOVER

                
=
 

                
1.
                      CA that directly supports an OCSP service<=
/span>

                
=
 

                
   When a CA
                      that directly supports an OCSP service performs a
                      key 

                
   rollover:

                
=
 

                
   - for
                      certificates issued under the old key, the CA
                      SHALL continue 

                
     to sign
                      the revocation status of OCSP responses with that
                      old key 

                
     at least
                      until all these certificates are expired, and

                
=
 

                
   - for
                      certificates issued under the new key, the CA
                      SHALL change the 

                
     accessLocation
                      in the AIA extension field of these certificates 

                
     and sign
                      the revocation status of OCSP responses with that
                      new key 

                
     at least
                      until all these certificates are expired.<=
/span>

                
=
 

                
   Note: The
                      change in accessLocation is necessary when the CA
                      rekeys 

                
         <=
/span>to
                      meet the following constraints imposed by this
                      standard: 

                
=
 

                
        &n=
bsp;   1)
                      a BasicOCSPResponse can only be signed using a
                      single 

                
        &n=
bsp;      private

                      key; 

                
=
 

                
        &n=
bsp;   2)
                      the response must be signed using the same CA key
                      that 

                
        &n=
bsp;      was used to
                      sign the certificate in question; and

                
=
 

                
        &n=
bsp;   3)
                      the OCSP response needs to cover all the
                      certificates 

                
        &n=
bsp;      queried
                      in the OCSP request.

                
 

                
2.
                      CA that uses OCSP responders
                
 

                
   When a CA
                      that uses OCSP Responders performs a key rollover,
                      then 

                
   it MUST
                      either designate a new OCSP Responder or keep the
                      current 

                
   OCSP
                      Responder(s).

                
=
 

                
   If the CA
                      designates a new OCSP Responder, then it SHALL
                      change the 

                
   accessLocation
                      in the AIA extension field for the newly issued =


                
   certificates
                      and issue an OCSP certificate to the new OCSP
                      Responder 

                
   using its
                      new key.

                
=
 

                
   If the CA
                      keeps the same OCSP Responder(s), then it SHALL
                      continue 

                
   to use the
                      same accessLocation(s) in the AIA extension field
                      for the 

                
   newly issued
                      certificates and issue an OCSP certificate to the
                      

                
   appropriate
                      OCSP Responder(s) using its new key.

                
=
 

                
   Note: The CA
                      may need to continue issuing certificates to the
                      OCSP 

                
   Responder(s)
                      using the old CA key until all the certificates
                      issued 

                
   under the
                      CA' old key for which the OCSP Responder(s) are =


                
   authoritative
                      have expired.

                
=
 

                
3.
                      OCSP Responder key rollover
=

                
=
 

                
   When an OCSP
                      Responder performs a key rollover (asynchronously
                      from 

                
   a CA key
                      rollover), then each CA which has designated an
                      OCSP 

                
   Responder
                      SHALL issue a new certificate for that OCSP
                      Responder and 

                
   for each of
                      its issuing keys which meets the following
                      property: 

                
=
 

                
      - the
                      issuing key has been used to sign at least one
                      certificate 

                
        =
which
                      contains an AIA extension designating that OCSP
                      Responder 

                
        =
and
                      that certificate is not yet expired.

                
=
 

                
   An OCSP
                      Responder key rollover does not affect the values
                      of the 

                
   URIs that
                      are placed in the accessLocation field from the
                      target 

                
   certificates.  One or more
                      OCSP Responder MAY respond to an OCSP 

                
   request
                      addressed at a given URI picked from the
                      accessLocation 

                
   field from a
                      target certificate.&nb=
sp;
                      Each OCSP Responder MAY use a 

                
   different
                      signing key, as long as it got an OCSP certificate
                      

                
   appropriate
                      for that signing key and for the target
                      certificate. 

                
 

                
 

                
31. Second
                    annex being proposed. This annex is important
                    because it describes the validation of an OCSP
                    response in the past 

                    which is of a particular importance when validating
                    electronic signatures.

                
 

                
Respo=
nse

                      processing by an OCSP client
                
=
 

                
   OCSP
                      responses can be verified at the current time by
                      an OCSP client 

                
   when
                      receiving a response, whereas old responses can be
                      verified at 

                
   a time in
                      the past by a verifier.  The algorithm
                      below addresses 

                
   both cases.<=
/b>

                
=
 

                
   Prior to
                      processing a basic response, OCSP clients MUST
                      determine 

                
   the checking
                      time, which may be either the current time or a
                      time 

                
   in the past.=


                
=
 

                
   OCSP clients
                      or verifiers SHALL check if the response contains
                      

                
   responseExtensions.
                      If such an extension is found and is recognized, 

                
   it MUST be
                      processed.  If
                      such a critical extension is found and 

                
   is not
                      recognized, the whole OCSP response MUST be
                      considered as 

                
   invalid.=


                
=
 

                
   If the
                      checking time is the current time, and if a nonce
                      extension 

                
   has been
                      used in the request and is recognized (see section
                      4.5.1), 

                
   OCSP clients
                      MUST check whether the same nonce is present in
                      the 

                
   response.  If the nonce
                      is not present or is different, then the <=
/span>

                
   OCSP
                      response MUST be discarded.
=

                
=
 

                
   Only the
                      single response(s) which are/is of interest SHALL
                      be 

                
   checked.=


                
=
 

                
STEP

                      1

                
=
 

                
   OCSP clients
                      or verifiers SHALL verify that the certificate <=
/o:p>

                
   identified
                      in a single response is of interest.  Otherwise,
                      proceed 

                
   to step 3.

                
=
 

                
   If the
                      certificate status included in a single
                      certificate response 

                
   is
                      "unknown", then the revocation status of that
                      certificate is 

                
   "unknown",
                      and proceed to step 3.

                
=
 

                
   If the
                      certificate status from the single certificate
                      response is 

                
   either
                      "good" or "revoked", OCSP clients or verifiers
                      SHALL check 

                
   that the
                      checking time is within the validity period of the
                      target 

                
   certificate.  If it is not
                      the case, then the revocation status of 

                
   that
                      certificate is "unknown" and proceed to step 3.<=
/o:p>

                
=
 

                
   If the
                      checking time is the current time, and if a nonce
                      has been 

                
   used in the
                      request, then proceed to step 2.

                
=
 

                
   If the
                      checking time is the current time, and if no nonce
                      has been 

                
   used in the
                      request, OCSP clients MUST check that the
                      producedAt

                
   field is
                      within a time window that is "close enough" to the
                      current 

                
   time. 
                
=
 

                
   Note: the
                      notion of "close enough" is a local matter.  It can be set
                      

                
         <=
/span>to a
                      few minutes to allow for small UTC time
                      differences 

                
         <=
/span>between
                      the client and the server or to a few hours in
                      case 

                
         <=
/span>the
                      server is producing pre-computed responses.

                
=
 

                
   If the
                      checking time is a time in the past, verifiers
                      MUST check 

                
   that the
                      producedAt field is in accordance with the
                      verification 

                
   rules (e.g.
                      close and/or after the date of a time-stamp
                      token).

                
=
 

                
   In addition,
                      if the nextUpdate field is present, OCSP clients
                      MUST 

                
   check that
                      the time which is indicated is greater than the
                      checking 

                
   time,
                      otherwise the single response MUST be discarded.=


                
=
 

                
   If checks
                      are successful, then OCSP clients MUST process the
                      

                
   singleExtensions

                      field, if it is present. 

                
=
 

                
   If the
                      criticality flag is set and the extension is not
                      understood, 

                
   then the
                      status of the certificate shall be "unknown" and
                      proceed to 

                
   step 3.  Otherwise,
                      proceed to step 2. 

                
=
 

                
   If the
                      extension is understood, then the extension MUST
                      be 

                
   processed.  According to
                      its content proceed either to step 2 or to 

                
   step 3. =


                
=
 

                
STEP

                      2

                
=
 

                
   OCSP clients
                      or verifiers MUST build and verify a certification
                      path 

                
   for that
                      certificate up to a trusted root, so that they
                      have the 

                
   knowledge of
                      the CA public key value that was used to sign the
                      

                
   target
                      certificate.  The
                      revocation status of each certificate of <=
/span>

                
   that
                      certification path (except the target certificate)
                      SHALL be 

                
   checked.=


                
=
 

                
   If no path
                      can be built or if one of the certificates of the
                      path is 

                
   revoked,
                      then the revocation status of that certificate is
                      "unknown", 

                
   and proceed
                      to step 3. 

                
=
 

                
   If the
                      certification path (except the target certificate)
                      is valid, 

                
   then two
                      cases need to be considered:
                
=
 

                
   a) If the
                      responderID matches with the name or the key from
                      the CA 

                
      which has
                      issued the target certificate, then check whether
                      the 

                
      OCSP
                      response is signed by the same key that was used
                      to sign 

                
      the
                      target certificate.

                
=
 

                
        &n=
bsp;    If
                      it is the case, then the revocation status of that
                      

                
        &n=
bsp;    certificate

                      as indicated in the certStatus field is 

                
        &n=
bsp;    accepted
                      and proceed to step 3.

                
=
 

                
        &n=
bsp;    If
                      it is not the case, then the revocation status of
                      that 

                
        &n=
bsp;    certificate

                      is "unknown" and proceed to step 3.=


                
=
 

                
   b) If the
                      responderID does not match with the name or the
                      key from 

                
      the CA
                      which has issued the target certificate, then it
                      indicates 

                
      the name
                      or the key from an OCSP Responder.  Check whether
                      there 

                
      exists a
                      local rule which applies to this target
                      certificate to 

                
      verify
                      that the signature of the BasicOCSPResponse is
                      valid for 

                
      that
                      single response. =
 If
                      this rule exists, it SHALL be followed. 

                
=
 

                
      Otherwise
                      check whether there is an OCSP certificate (i.e.
                      which 

                
      has both
                      the ocspSigning OID in the extended key usage
                      extension 

                
      and the
                      digitalSignature bit in the key usage extension)
                      signed 

                
      by the
                      same key that was used to sign the target
                      certificate. 

                
      This
                      certificate MUST be present in the certs field
                      from the 

                
      BasicOCSPRes=
ponse.

                      

                
=
 

                
        &n=
bsp; If
                      such certificate is not found or is invalid, then
                      the 

                
        &n=
bsp; revocation

                      status of that certificate is "unknown" and 

                
        &n=
bsp; proceed
                      to step 3.

                
=
 

                
        &n=
bsp; If
                      such certificate exists and if the checking time
                      is 

                
        &n=
bsp; within
                      the validity period of this certificate, then it
                      MUST 

                
        &n=
bsp; be
                      verified whether the OCSP response can be verified
                      using 

                
        &n=
bsp; the
                      public key that is present in the OCSP
                      Certificate. 

                
=
 

                
        &n=
bsp;    If
                      it is not the case, then the revocation status of
                      that 

                
        &n=
bsp;    certificate

                      is "unknown" and proceed to step 3.=


                
=
 

                
        &n=
bsp;    If
                      it is the case, then it MUST be verified that the
                      OCSP 

                
        &n=
bsp;    Certificate

                      has not been revoked.

                
=
 

                
     If one of
                      these conditions is met, then the status for the
                      target 

                
     certificate
                      as indicated in the certStatus field is accepted,
                      

                
     otherwise
                      the revocation status is "unknown".=


                
=
 

                
STEP

                      3

                
=
 

                
   If there
                      exists another single certificate status response
                      for a 

                
   target
                      certificate that is of interest, then proceed to
                      step 1. 

                
   Otherwise
                      the basic response is now processed.

                
 

                
 

                
32. Third
                    annex being proposed. This annex is important
                    because it provides guidance on how to build an OCSP
                    responder in the three cases. 

                    Many text portions are similar, but three full texts
                    are provided in order to provide a better clarity
                    for each of the three cases.

                
 

                
1.
                      Request processing by OCSP servers<=
/b>

                
=
 

                
   The behavior
                      of an OCSP server will be different whether the
                      OCSP 

                
   server is a
                      CA acting as an OCSP responder, is an OCSP
                      Responder 

                
   which
                      received a delegation from one or more CAs, or is
                      a locally 

                
   trusted
                      Responder.

                
=
 

                
1.1.

                      Processing by a CA acting as an OCSP responder

                
=
 

                
   The OCSP
                      responder SHALL maintain a list of entries. Each
                      entry 

                
   SHALL
                      contain:

                
=
 

                
     - the URI
                      associated to the OCSP responder, from which the
                      OCSP 

                
       reques=
ts
                      are received, 

                
=
 

                
     - the DN
                      from a CA,

                
=
 

                
     - an
                      issuing public key from a CA,
                
=
 

                
     - the
                      method(s) used to know for which subset of
                      certificates 

                
       issued=

                      by the CA it is responsible for, 

                
=
 

                
     - the
                      method(s) used to obtain the revocation status of
                      that 

                
       subset=

                      of certificates issued under that CA issuing
                      public key, 

                
       and

                
=
 

                
     - the
                      method used to gain access and sign with the
                      private key 

                
       corres=
ponding
                      to the issuing public key.

                
=
 

                
   For a given
                      URI value, the OCSP responder SHALL only use one
                      CA 

                
   key pair
                      value. 

                
=
 

                
   When it
                      receives an OCSP request on that URI, the OCSP
                      responder 

                
   SHALL handle
                      exceptions according to section 2.3. 

                
=
 

                
   If the OCSP
                      request contains the name of a requestor, the OCSP
                      

                
   responder
                      SHALL verify whether there exists a locally
                      defined rule 

                
   which
                      regulates access control.  If this rule
                      exists, it SHALL be 

                
   followed.

                
=
 

                
   Then, for
                      each target certificate, the OCSP responder SHALL
                      verify 

                
   whether both
                      the hash of the issuer's DN and the hash of the
                      issuer 

                
   public key
                      which are present in the request are eligible to a
                      

                
   locally
                      defined rule which indicates that the OCSP
                      responder is 

                
   responsible
                      to provide the revocation status of that target =


                
   certificate.  If this rule
                      exists, it SHALL be followed.
                
=
 

                
   Otherwise,
                      the OCSP responder SHALL determine whether it is 

                
   responsible
                      to provide the revocation status of that target =


                
   certificate
                      according to the following rule.

                
=
 

                
   For each
                      target certificate, the OCSP responder SHALL
                      verify whether 

                
   both the
                      hash of the issuer's DN and the hash of the issuer
                      public 

                
   key which
                      are present in the request match respectively with
                      the DN 

                
   and the hash
                      of the public key of contained in an entry from
                      the 

                
   list of
                      entries maintained by this OCSP responder. 

                
=
 

                
   When there
                      is no match, then the OCSP responder SHALL
                      indicate the 

                
   "unknown"
                      status and proceed with the next target
                      certificate from 

                
   the OCSP
                      request.

                
=
 

                
   When there
                      is a match, then the OCSP responder SHALL use the
                      serial 

                
   number of
                      the target certificate that is present in the
                      request and 

                
   determine
                      the revocation status of that certificate
                      according to 

                
   the
                      method(s) defined in the entry. 

                
=
 

                
   When the
                      revocation status is provided by the server using
                      a real 

                
   time access
                      to a database of revocation statuses of issued <=
/o:p>

                
   certificates,
                      then the thisUpdate field SHALL be present in the

                
   SingleResponse

                      response whereas the nextUpdate field SHALL be <=
/o:p>

                
   missing. 

                
=
 

                
   Otherwise,
                      both the thisUpdate and the nextUpdate fields
                      SHALL be 

                
   present in
                      the SingleResponse. 

                
=
 

                
   The time at
                      which this response will be signed MUST be
                      indicated in 

                
   the
                      producedAt field from the SingleResponse.<=
/span>

                
=
 

                
   If a
                      singleRequestExtensions is present in the request
                      it MUST be 

                
   processed.

                
=
 

                
   If there is
                      another target certificate present in the request,
                      it 

                
   SHALL be
                      processed in the same way.

                
=
 

                
   If a
                      requestExtensions is present in the request it
                      MUST be 

                
   processed.

                
=
 

                
   The OCSP
                      response MUST be signed using the CA issuing
                      private key.

                
=
 

                
=
 

                
1.2.

                      Processing by an OCSP Responder=


                
=
 

                
   For each CA
                      from which the OCSP Responder has received a
                      delegation, 

                
   the OCSP
                      Responder SHALL maintain a list of entries. 

                
=
 

                
   Each entry
                      SHALL contain:

                
=
 

                
     - the URI
                      associated to this OCSP Responder, from which the
                      OCSP 

                
       reques=
ts
                      are received, 

                
=
 

                
     - the DN
                      from a CA,

                
=
 

                
     - an
                      issuing public key from a CA,
                
=
 

                
     - the
                      method(s) used to know for which subset of
                      certificates 

                
       issued=

                      by the CA it is responsible for, 

                
=
 

                
     - the
                      method(s) used to obtain the revocation status of
                      that 

                
       subset=

                      of certificates issued under that CA issuing
                      public key,

                
=
 

                
     - an OCSP
                      certificate, 

                
=
 

                
     - the OCSP
                      public key contained in that OCSP certificate, and

                
=
 

                
     - the
                      method used to gain access and sign with the OCSP
                      private 

                
       key
                      corresponding to that OCSP certificate.

                
=
 

                
   For a given
                      URI value, the OCSP Responder SHALL only use one
                      OCSP 

                
   key pair
                      value.  Th=
erefore
                      there cannot be two entries with the 

                
   same URI
                      value and a different OCSP public key value.

                
=
 

                
   NOTE: a
                      BasicOCSPResponse can only be signed using a
                      single private 

                
         <=
/span>key. 

                
=
 

                
   The OCSP
                      certificate SHALL be signed by the CA issuing
                      private key 

                
   which
                      corresponds to the issuing CA public key that is
                      in this 

                
   entry.
                
=
 

                
   When it
                      receives an OCSP request, the OCSP responder SHALL
                      handle 

                
   exceptions
                      according to section 2.3. 

                
=
 

                
   If the OCSP
                      request contains the name of a requestor, the OCSP
                      

                
   responder
                      SHALL verify whether there exists a locally
                      defined rule 

                
   which
                      regulates access control.  If this rule
                      exists, it SHALL be 

                
   followed.

                
=
 

                
   For each
                      target certificate, the OCSP Responder SHALL
                      verify 

                
   whether both
                      the hash of the issuer's DN and the hash of the
                      issuer 

                
   public key
                      which are present in the OCSP request match with
                      those 

                
   from an
                      entry.

                
=
 

                
   When there
                      is no match, then the OCSP Responder SHALL
                      indicate the 

                
   "unknown"
                      status and proceed with the next target
                      certificate from 

                
   the OCSP
                      request.

                
=
 

                
   When there
                      is a match, the OCSP Responder SHALL use the
                      serial 

                
   number of
                      the target certificate this is present in the OCSP
                      

                
   request to
                      determine the revocation status of that
                      certificate 

                
   according to
                      the method(s) indicated in the entry. 

                
=
 

                
   When the
                      revocation status is provided by the server using
                      a real 

                
   time access
                      to a database of revocation statuses of issued <=
/o:p>

                
   certificates,
                      then the thisUpdate field SHALL be present in the

                
   SingleResponse

                      response whereas the nextUpdate field SHALL be <=
/o:p>

                
   missing. 

                
=
 

                
   Otherwise,
                      both the thisUpdate and the nextUpdate fields
                      SHALL be 

                
   present in
                      the SingleResponse. 

                
=
 

                
   The time at
                      which this response will be signed MUST be
                      indicated in 

                
   the
                      producedAt field from the SingleResponse.<=
/span>

                
=
 

                
   If a
                      singleRequestExtensions is present in the request
                      it MUST be 

                
   processed.

                
=
 

                
   If there is
                      another target certificate present in the request,
                      it 

                
   SHALL be
                      processed in the same way.

                
=
 

                
   If a
                      requestExtensions is present in the request it
                      SHALL be 

                
   processed.

                
=
 

                
   The OCSP
                      response MUST be signed using the OCSP private
                      key.

                
=
 

                
   Unless there
                      is a local rule which states differently, for
                      every 

                
   target
                      certificate which matches both with the hash of a
                      CA DN and an 

                
   issuing
                      public key from an entry, the OCSP certificate of
                      that entry 

                
   SHALL be
                      placed in the certs field.

                
=
 

                
   It may
                      happen, that none of the target certificates from
                      the OCSP

                
   request
                      matches both with the hash of a CA DN and an
                      issuing public 

                
   key from an
                      entry.  In=

                      that case and unless a local rule states <=
/span>

                
   differently,
                      the certs field from the BasicOCSPResponse SHOULD
                      be 

                
   kept empty
                      (to limit the disclose of the names of the CAs
                      from which 

                
   the OCSP
                      Responder received a delegation from).

                
=
 

                
1.3.

                      Processing by a locally trusted Responder<=
/span>

                
=
 

                
   For each CA
                      for which the locally trusted Responder is 

                
   authoritative,
                      the OCSP Responder SHALL maintain a list of
                      entries. 

                
=
 

                
   Each entry
                      SHALL contain:

                
=
 

                
     - the URI
                      associated to this OCSP Responder, from which the
                      OCSP 

                
       reques=
ts
                      are received, 

                
=
 

                
     - the DN
                      from a CA,

                
=
 

                
     - an
                      issuing public key from a CA,
                
=
 

                
     - the
                      method(s) used to know for which subset of
                      certificates 

                
       issued=

                      by the CA it is responsible for, 

                
=
 

                
     - the
                      method(s) used to obtain the revocation status of
                      that 

                
       subset=

                      of certificates issued under that CA issuing
                      public key,

                
=
 

                
     - the
                      method used to gain access to the private key in
                      order to 

                
       sign t=
he
                      OCSP response. 

                
=
 

                
   For a given
                      URI value, the OCSP Responder SHALL only use one
                      private 

                
   key.  Therefore
                      there cannot be two entries with the same URI
                      value 

                
   and a
                      different method to gain access to the appropriate
                      private key.

                
=
 

                
   NOTE: a
                      BasicOCSPResponse can only be signed using a
                      single private 

                
         <=
/span>key. 

                
=
 

                
   When it
                      receives an OCSP request, the OCSP responder SHALL
                      handle 

                
   exceptions
                      according to section 2.3. 

                
=
 

                
   If the OCSP
                      request contains the name of a requestor, the OCSP
                      

                
   responder
                      SHALL verify whether there exists a locally
                      defined rule 

                
   which
                      regulates access control.  If this rule
                      exists, it SHALL be 

                
   followed.

                
=
 

                
   For each
                      target certificate, the OCSP Responder SHALL
                      verify 

                
   whether both
                      the hash of the issuer's DN and the hash of the
                      issuer 

                
   public key
                      which are present in the OCSP request match with
                      those 

                
   from an
                      entry.

                
=
 

                
   When there
                      is no match, then the OCSP Responder SHALL
                      indicate the 

                
   "unknown"
                      status and proceed with the next target
                      certificate from 

                
   the OCSP
                      request.

                
=
 

                
   When there
                      is a match, the OCSP Responder SHALL use the
                      serial 

                
   number of
                      the target certificate this is present in the OCSP
                      

                
   request to
                      determine the revocation status of that
                      certificate 

                
   according to
                      the method(s) indicated in the entry. 

                
=
 

                
   When the
                      revocation status is provided by the server using
                      a real 

                
   time access
                      to a database of revocation statuses of issued <=
/o:p>

                
   certificates,
                      then the thisUpdate field SHALL be present in the

                
   SingleResponse

                      response whereas the nextUpdate field SHALL be <=
/o:p>

                
   missing. 

                
=
 

                
   Otherwise,
                      both the thisUpdate and the nextUpdate fields
                      SHALL be 

                
   present in
                      the SingleResponse. 

                
=
 

                
   The time at
                      which this response will be signed MUST be
                      indicated in 

                
   the
                      producedAt field from the SingleResponse.<=
/span>

                
=
 

                
   If a
                      singleRequestExtensions is present in the request
                      it MUST be 

                
   processed.

                
=
 

                
   If there is
                      another target certificate present in the request,
                      it 

                
   SHALL be
                      processed in the same way.

                
=
 

                
   If a
                      requestExtensions is present in the request it
                      SHALL be 

                
   processed.

                
=
 

                
   The OCSP
                      response MUST be signed using the OCSP private
                      key.

                
=
 

                
   The certs
                      field may contain no, one or several OCSP
                      certificates 

                
   according to
                      local rules followed by the locally trusted
                      Responder.

              

          

        

      
      


      

      
Not broken.

      


      

      
/Stefan

      


      

      
        

          

            

                
 

                
 

                
End of
                    comments

                  

                


                  Denis

                  <=
/o:p>

                
 

               

          

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

      
    

    

  

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/m=
ailman/listinfo/pkix



--B_3443590283_11353265--



From stefan@aaa-sec.com  Wed Feb 13 00:03:58 2013
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 DF89621F8922 for ; Wed, 13 Feb 2013 00:03:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.587
X-Spam-Level: 
X-Spam-Status: No, score=-101.587 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 EzKILoW1GcY7 for ; Wed, 13 Feb 2013 00:03:58 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFBE21F8AC8 for ; Wed, 13 Feb 2013 00:03:58 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id F08043B53AD for ; Wed, 13 Feb 2013 09:03:56 +0100 (CET)
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 BFu9hjp5NGHs for ; Wed, 13 Feb 2013 09:03:53 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id CFA393B5A02 for ; Wed, 13 Feb 2013 09:02:09 +0100 (CET)
Received: (qmail 54187 invoked from network); 13 Feb 2013 08:02:09 -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 ; 13 Feb 2013 08:02:09 -0000
User-Agent: Microsoft-MacOutlook/14.3.0.121105
Date: Wed, 13 Feb 2013 09:02:06 +0100
From: Stefan Santesson 
To: 
Message-ID: 
Thread-Topic: [pkix] AuthContext Certificate extension
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] AuthContext Certificate 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: Wed, 13 Feb 2013 08:03:59 -0000

I was made aware that the document link no longer works:

Here is a link to the latest current draft:
http://tools.ietf.org/html/draft-santesson-auth-context-extension


Thanks to Jim for checking nits and the ASN.1 modules!

/Stefan



On 2/12/13 1:15 PM, "Stefan Santesson"  wrote:

>I hav submitted a new draft as an individual submission:
>
>http://www.ietf.org/id/draft-santesson-auth-context-extension-00.txt
>
>Abstract
>
>   This document defines an extension to certificates according to
>   [RFC5280]. The extension defined in this document holds data about
>   how the certificate subject was authenticated by the Certification
>   Authority who issued the certificate where this extension appears.
>
>   This document also defines one data structure for inclusion in this
>   extension that designed to hold information when the subject is
>   authenticated using a SAML assertion [SAML].
>
>
>
>
>This draft documents an extension that we have defined in the Swedish
>national electronic identification infrastructure in order to be able to
>match SAML credentials with associated electronic signatures.
>All signature certificates are issued by a central signature generation
>service which authenticates the user using SAML credentials and then adds
>this extension to the certificate.
>
>This makes it possible for service providers to compare the signer of a
>document with the entity currently logged into the service using SAML.
>
>I would have loved for this to be part of the PKIX process, but as we are
>not allowed to take on any further work, I let this do as an individual
>submission.
>
>Currently the draft is based on the Swedish defined OIDs.
>
>There is still a short window before we need to lock this specification in
>the Swedish project, but I'm very interested in review from members of
>this group.
>The intention is currently to go Informational, in order to just provide a
>stable reference to this extension definition.
>Should there be an interest in moving this to standards track, then I
>would not object to doing so.
>
>/Stefan
>
>
>
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix



From pkix@inbox.lv  Mon Feb 18 04:49:55 2013
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 2BF0021F887F for ; Mon, 18 Feb 2013 04:49:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.315
X-Spam-Level: 
X-Spam-Status: No, score=-1.315 tagged_above=-999 required=5 tests=[AWL=-1.685, BAYES_40=-0.185, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, 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 2cdkPbt2mZKh for ; Mon, 18 Feb 2013 04:49:53 -0800 (PST)
Received: from shark4.inbox.lv (shark4.inbox.lv [89.111.3.84]) by ietfa.amsl.com (Postfix) with ESMTP id 979A221F884F for ; Mon, 18 Feb 2013 04:49:52 -0800 (PST)
Received: by shark4.inbox.lv (Postfix, from userid 1000) id 2EE7F25FEC; Mon, 18 Feb 2013 14:49:48 +0200 (EET)
Received: from localhost (localhost [127.0.0.1]) by shark4-plain-b64d2.inbox.lv (Postfix) with ESMTP id F1EB725F82 for ; Mon, 18 Feb 2013 14:49:47 +0200 (EET)
Received: from localhost ([10.0.1.11]) by localhost (shark4.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id LQUbeaXta9Ci for ; Mon, 18 Feb 2013 14:49:47 +0200 (EET)
Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Mon, 18 Feb 2013 14:49:47 +0200
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Compose: web=mail.inbox.lv, node=w1.inbox.lv, l=en, compose=HTML
X-REMOTE-ADDR: 193.40.12.10
X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Ubuntu Chromium/24.0.1312.56 Chrome/24.0.1312.56 Safari/537.17
Message-ID: <1361191787.5122236bed12c@mail.inbox.lv>
Date: Mon, 18 Feb 2013 14:49:47 +0200
From: "Andris Berzins" 
To: pkix@ietf.org
User-Agent: Inbox.lv Webmail
Subject: [pkix] purpose of LDAP in PKI
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, 18 Feb 2013 12:49:55 -0000


 
 
 
=
Hello,
 
What could be the reason why end user certificates shoul=
d be stored in LDAP by the CA and made publicly available?


(I might understand the reason for storing CRLs (LDAP as an alternative to=
 HTTP).)


From pgut001@cs.auckland.ac.nz  Mon Feb 18 05:38:39 2013
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 4055A21F87AF for ; Mon, 18 Feb 2013 05:38:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.381
X-Spam-Level: 
X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218,  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 Z1uhVuNJQXzG for ; Mon, 18 Feb 2013 05:38:38 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 1109D21F875F for ; Mon, 18 Feb 2013 05:38:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1361194718; x=1392730718; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=djVkuk8P9lYQl06AO8kPCP1mBxCZHaGkgzhSuiNFMic=; b=GZx8dRTV2EtkgTAOVtchy59TF/s65EJliKuDv0GPfon0Re9pbReg5Ws6 1KTer7U6yHgSg3qnTCGBcHPpG02e1aTG9eNMjgD3t8anf19+HOzHX8FNq 9dQ8blpAqe4LUNxjZeKH6SU5HK18z5SyUhehftr4+KgFmbkwsFqVulIcO U=;
X-IronPort-AV: E=Sophos;i="4.84,688,1355050800"; d="scan'208";a="170988846"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Feb 2013 02:38:36 +1300
Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.108]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 02:38:36 +1300
From: Peter Gutmann 
To: "pkix@ietf.org" 
Thread-Topic: [pkix] purpose of LDAP in PKI
Thread-Index: Ac4N3T/yho4nk/8wRB68KSNUgoj19A==
Date: Mon, 18 Feb 2013 13:38:35 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [pkix]  purpose of LDAP in PKI
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, 18 Feb 2013 13:38:39 -0000

Andris Berzins  writes:=0A=
=0A=
>What could be the reason why end user certificates should be stored in LDA=
P=0A=
>by the CA and made publicly available?=0A=
=0A=
There isn't one.  It's (ancient) historical baggage based on X.509's origin=
s=0A=
in X.500, and some of the people writing the standards haven't realised yet=
=0A=
that HTTP won.=0A=
=0A=
Peter.=0A=

From pkix@inbox.lv  Mon Feb 18 05:53:16 2013
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 329C021F8910 for ; Mon, 18 Feb 2013 05:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level: 
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[AWL=0.365,  BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, 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 5BIMngP040Ta for ; Mon, 18 Feb 2013 05:53:15 -0800 (PST)
Received: from shark2.inbox.lv (shark2.inbox.lv [89.111.3.82]) by ietfa.amsl.com (Postfix) with ESMTP id A531F21F890D for ; Mon, 18 Feb 2013 05:53:15 -0800 (PST)
Received: by shark2.inbox.lv (Postfix, from userid 1000) id C3FE2D867; Mon, 18 Feb 2013 15:53:13 +0200 (EET)
Received: from localhost (localhost [127.0.0.1]) by shark2-plain-b64d2.inbox.lv (Postfix) with ESMTP id 6FE07D855 for ; Mon, 18 Feb 2013 15:53:13 +0200 (EET)
Received: from localhost ([10.0.1.19]) by localhost (shark2.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id AkQM4UjvrnHf for ; Mon, 18 Feb 2013 15:53:11 +0200 (EET)
Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Mon, 18 Feb 2013 15:53:11 +0200
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Compose: web=mail.inbox.lv, node=w9.inbox.lv, l=en, compose=HTML
X-REMOTE-ADDR: 193.40.12.10
X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Ubuntu Chromium/24.0.1312.56 Chrome/24.0.1312.56 Safari/537.17
Message-ID: <1361195591.51223247ad553@mail.inbox.lv>
Date: Mon, 18 Feb 2013 15:53:11 +0200
From: "Andris Berzins" 
To: pkix@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz>
User-Agent: Inbox.lv Webmail
Subject: Re: [pkix] purpose of LDAP in PKI
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, 18 Feb 2013 13:53:16 -0000


 
 

 
 
Quoting Peter Gutmann <pgut001@cs.auckland.ac.nz>:
 
Andris Berzins <pkix@inbox.lv> writes:
 
 >Wha=
t could be the reason why end user certificates should be stored in LDAP >by the CA and made publicly available?
 
 There isn't one=
=2E  It's (ancient) historical baggage based on X.509's origins
 in X=
=2E500, and some of the people writing the standards haven't realised yet that HTTP won.


When I apply for ID-card having=
 authentication and qualified signature certificate on it,
I have to c=
heckbox whether I want my certificates to be published in LDAP.
I get =
no clear answer how could I benefit from my certificates being published.


 
 Peter.
 ________=
_______________________________________
 pkix mailing list
 pkix@=
ietf.org
 https://www.ietf.org/mailman/listinfo/pkix

 
 




From denis.pinkas@bull.net  Mon Feb 18 06:00:19 2013
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 15E0921F886B for ; Mon, 18 Feb 2013 06:00:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.648
X-Spam-Level: 
X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 uqlcSma93pdl for ; Mon, 18 Feb 2013 06:00:18 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id B9EA421F87B2 for ; Mon, 18 Feb 2013 06:00:17 -0800 (PST)
Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id CBDEE1D1DB for ; Mon, 18 Feb 2013 15:00:16 +0100 (CET)
Received: from [127.0.0.1] ([129.182.108.120]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2013021815001640-37354 ; Mon, 18 Feb 2013 15:00:16 +0100 
Message-ID: <512233EC.4060807@bull.net>
Date: Mon, 18 Feb 2013 15:00:12 +0100
From: Denis Pinkas 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: pkix@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz> <1361195591.51223247ad553@mail.inbox.lv>
In-Reply-To: <1361195591.51223247ad553@mail.inbox.lv>
X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 18/02/2013 15:00:16, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 18/02/2013 15:00:16, Serialize complete at 18/02/2013 15:00:16
X-TNEFEvaluated: 1
Content-Type: multipart/alternative; boundary="------------030107040300070300010903"
Subject: Re: [pkix] purpose of LDAP in PKI
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, 18 Feb 2013 14:00:19 -0000

This is a multi-part message in MIME format.
--------------030107040300070300010903
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Andris,

Making certificates publicly available may only be done with the 
agreement of the end-user.

There are no benefits for certificates being used for authentication or 
non repudiation, but only inconveniences: .
in particular : lack of privacy, and ability to know how many customers 
the CAs has.

Denis

>
>
>
> Quoting *Peter Gutmann  
> *:
>
>     Andris Berzins  writes:
>
>     >What could be the reason why end user certificates should be
>     stored in LDAP
>     >by the CA and made publicly available?
>
>     There isn't one. It's (ancient) historical baggage based on
>     X.509's origins
>     in X.500, and some of the people writing the standards haven't
>     realised yet
>     that HTTP won.
>
>
>
> When I apply for ID-card having authentication and qualified signature 
> certificate on it,
> I have to checkbox whether I want my certificates to be published in LDAP.
> I get no clear answer how could I benefit from my certificates being 
> published.
>
>
>
>
>     Peter.
>     _______________________________________________
>     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


--------------030107040300070300010903
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=ISO-8859-1


  
    
  
  
    
Andris,

      

      Making certificates publicly available may only be done with the
      agreement of the end-user.

      

      There are no benefits for certificates being used for
      authentication or non repudiation, but only inconveniences: .

      in particular : lack of privacy, and ability to know how many
      customers the CAs has. 

      

      Denis

      

    

    


      
 

      

      

      
Quoting Peter Gutmann <pgut001@cs.auckland.ac.nz>:

      
Andris Berzins
        <pkix@inbox.lv> writes:

        

        >What could be the reason why end user certificates should be
        stored in LDAP

        >by the CA and made publicly available?

        

        There isn't one. It's (ancient) historical baggage based on
        X.509's origins

        in X.500, and some of the people writing the standards haven't
        realised yet

        that HTTP won.

      

      

      When I apply for ID-card having authentication and qualified
      signature certificate on it,

      I have to checkbox whether I want my certificates to be published
      in LDAP.

      I get no clear answer how could I benefit from my certificates
      being published.

      

      

      

      
 

        Peter.

        _______________________________________________

        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


    

    

  


--------------030107040300070300010903--


From bilal.ashraf@ascertia.com  Mon Feb 18 06:06:34 2013
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 80C0A21F88DB for ; Mon, 18 Feb 2013 06:06:34 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BQl+yvq6Gg3 for ; Mon, 18 Feb 2013 06:06:33 -0800 (PST)
Received: from mail.ascertia.com (www.ascertia.com [94.136.44.32]) by ietfa.amsl.com (Postfix) with ESMTP id 905B821F886B for ; Mon, 18 Feb 2013 06:06:33 -0800 (PST)
Received: from [192.168.0.85] ([202.141.240.172]) by ascertia.com with MailEnable ESMTP; Mon, 18 Feb 2013 14:08:48 +0000
Message-ID: <5122351B.1070804@ascertia.com>
Date: Mon, 18 Feb 2013 19:05:15 +0500
From: Bilal Ashraf 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Andris Berzins 
References: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz> <1361195591.51223247ad553@mail.inbox.lv>
In-Reply-To: <1361195591.51223247ad553@mail.inbox.lv>
Content-Type: multipart/alternative; boundary="------------040101040805060102030909"
Cc: pkix@ietf.org
Subject: Re: [pkix] purpose of LDAP in PKI
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, 18 Feb 2013 14:06:34 -0000

This is a multi-part message in MIME format.
--------------040101040805060102030909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

One possible use case could be that others can use your certificate=20
(from LDAP) for encryption e.g. sending encrypted emails or encrypted=20
documents to you.

The other possible use case could be SSL client authentication where=20
certificates are presented by client and matched by applications against =

user certificates published at LDAP.

Regards,
Bilal.

On 2/18/2013 6:53 PM, Andris Berzins wrote:
>
>
>
> Quoting *Peter Gutmann =20
> *:
>
>     Andris Berzins  writes:
>
>     >What could be the reason why end user certificates should be
>     stored in LDAP
>     >by the CA and made publicly available?
>
>     There isn't one. It's (ancient) historical baggage based on
>     X.509's origins
>     in X.500, and some of the people writing the standards haven't
>     realised yet
>     that HTTP won.
>
>
>
> When I apply for ID-card having authentication and qualified signature =

> certificate on it,
> I have to checkbox whether I want my certificates to be published in LD=
AP.
> I get no clear answer how could I benefit from my certificates being=20
> published.
>
>
>
>
>     Peter.
>     _______________________________________________
>     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


--------------040101040805060102030909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit


  
    
  
  
    
One possible use case could be that
      others can use your certificate (from LDAP) for encryption e.g.
      sending encrypted emails or encrypted documents to you. 

      

      The other possible use case could be SSL client authentication
      where certificates are presented by client and matched by
      applications against user certificates published at LDAP.

      

      Regards,

      Bilal.

      

      On 2/18/2013 6:53 PM, Andris Berzins wrote:

    

    


      
 

      

      

      
Quoting Peter Gutmann <pgut001@cs.auckland.ac.nz>:

      
Andris Berzins
        <pkix@inbox.lv> writes:

        

        >What could be the reason why end user certificates should be
        stored in LDAP

        >by the CA and made publicly available?

        

        There isn't one. It's (ancient) historical baggage based on
        X.509's origins

        in X.500, and some of the people writing the standards haven't
        realised yet

        that HTTP won.

      

      

      When I apply for ID-card having authentication and qualified
      signature certificate on it,

      I have to checkbox whether I want my certificates to be published
      in LDAP.

      I get no clear answer how could I benefit from my certificates
      being published.

      

      

      

      
 

        Peter.

        _______________________________________________

        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


    

    

  


--------------040101040805060102030909--


From Walter.Goulet@rsa.com  Mon Feb 18 06:09:10 2013
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 B486021F8970 for ; Mon, 18 Feb 2013 06:09:10 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK7ZGRe+zCSY for ; Mon, 18 Feb 2013 06:09:06 -0800 (PST)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8656B21F8906 for ; Mon, 18 Feb 2013 06:09:06 -0800 (PST)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1IE900s022874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2013 09:09:03 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 18 Feb 2013 09:08:38 -0500
Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1IE8bAT025859; Mon, 18 Feb 2013 09:08:37 -0500
Received: from mx32a.corp.emc.com ([169.254.1.81]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Mon, 18 Feb 2013 09:08:37 -0500
From: "Goulet, Walter" 
To: Andris Berzins , "pkix@ietf.org" 
Date: Mon, 18 Feb 2013 09:08:35 -0500
Thread-Topic: [pkix] purpose of LDAP in PKI
Thread-Index: Ac4N33dRryM08jnKSGWqJaL3n+0hNAAAWPQw
Message-ID: <1F94BBCDF9E6E7438147ABA3C338441A01594CEA16@MX32A.corp.emc.com>
References: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz> <1361195591.51223247ad553@mail.inbox.lv>
In-Reply-To: <1361195591.51223247ad553@mail.inbox.lv>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [pkix] purpose of LDAP in PKI
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, 18 Feb 2013 14:09:10 -0000

DQpRdW90aW5nIFBldGVyIEd1dG1hbm4gPHBndXQwMDFAY3MuYXVja2xhbmQuYWMubno+Og0KQW5k
cmlzIEJlcnppbnMgPHBraXhAaW5ib3gubHY+IHdyaXRlczoNCg0KPj4+V2hhdCBjb3VsZCBiZSB0
aGUgcmVhc29uIHdoeSBlbmQgdXNlciBjZXJ0aWZpY2F0ZXMgc2hvdWxkIGJlIHN0b3JlZCBpbiBM
REFQDQo+Pj5ieSB0aGUgQ0EgYW5kIG1hZGUgcHVibGljbHkgYXZhaWxhYmxlPw0KDQo+PlRoZXJl
IGlzbid0IG9uZS4gSXQncyAoYW5jaWVudCkgaGlzdG9yaWNhbCBiYWdnYWdlIGJhc2VkIG9uIFgu
NTA5J3Mgb3JpZ2lucw0KPj5pbiBYLjUwMCwgYW5kIHNvbWUgb2YgdGhlIHBlb3BsZSB3cml0aW5n
IHRoZSBzdGFuZGFyZHMgaGF2ZW4ndCByZWFsaXNlZCB5ZXQNCj4+dGhhdCBIVFRQIHdvbi4NCg0K
DQo+V2hlbiBJIGFwcGx5IGZvciBJRC1jYXJkIGhhdmluZyBhdXRoZW50aWNhdGlvbiBhbmQgcXVh
bGlmaWVkIHNpZ25hdHVyZSBjZXJ0aWZpY2F0ZSBvbiBpdCwNCj5JIGhhdmUgdG8gY2hlY2tib3gg
d2hldGhlciBJIHdhbnQgbXkgY2VydGlmaWNhdGVzIHRvIGJlIHB1Ymxpc2hlZCBpbiBMREFQLg0K
PkkgZ2V0IG5vIGNsZWFyIGFuc3dlciBob3cgY291bGQgSSBiZW5lZml0IGZyb20gbXkgY2VydGlm
aWNhdGVzIGJlaW5nIHB1Ymxpc2hlZC4NCg0KSW4gZW50ZXJwcmlzZSBvciBvdGhlciBwcml2YXRl
IFBLSSBkZXBsb3ltZW50cyBwdWJsaXNoaW5nIGNlcnRpZmljYXRlcyB0byBMREFQIHN0b3JlcyBj
YW4gYmUgdmVyeSB1c2VmdWwgZm9yIGFwcGxpY2F0aW9ucyBzdWNoIGFzIFMvTUlNRSB3aGVyZSBh
IHNlbmRlcidzIG1haWwgY2xpZW50IGNhbiBmZXRjaCBhIHJlY2lwaWVudCdzIGNlcnRpZmljYXRl
IGZyb20gYSBjZW50cmFsaXplZCBMREFQIGRpcmVjdG9yeSBzZXJ2aWNlLiBCYXNpY2FsbHksIGV4
cG9zaW5nIHlvdXIgY2VydGlmaWNhdGUgdmlhIExEQVAgbWFrZXMgaXQgKm11Y2gqIGVhc2llciBm
b3Igb3RoZXIgYXBwbGljYXRpb25zIHRvIGFjdHVhbGx5IHVzZSB5b3VyIGNlcnRpZmljYXRlLg0K
DQpUaGUgYmVuZWZpdHMgb2YgcHVibGlzaGluZyB5b3VyIGNlcnRpZmljYXRlIHB1YmxpY2x5IChp
LmUuIG92ZXIgSW50ZXJuZXQgYWNjZXNzaWJsZSBMREFQIGRpcmVjdG9yeSBzdG9yZSkgYXJlIGxl
c3MgY2xlYXIgdG8gbWUuIA0KDQoNClBldGVyLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCnBraXggbWFpbGluZyBsaXN0DQpwa2l4QGlldGYub3JnDQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXgNCg0KwqANCg0K

From joel.kazin1@verizon.net  Mon Feb 18 06:18:55 2013
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 0C9FC21F88F0 for ; Mon, 18 Feb 2013 06:18:55 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfeJjOGLppUp for ; Mon, 18 Feb 2013 06:18:54 -0800 (PST)
Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by ietfa.amsl.com (Postfix) with ESMTP id 6168A21F87F9 for ; Mon, 18 Feb 2013 06:18:54 -0800 (PST)
Received: from [192.168.2.2] ([unknown] [96.239.23.68]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MIF007H96EL3S20@vms173003.mailsrvcs.net> for pkix@ietf.org; Mon, 18 Feb 2013 08:18:33 -0600 (CST)
Message-id: <5122382D.5090904@verizon.net>
Date: Mon, 18 Feb 2013 09:18:21 -0500
From: Joel Kazin 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-version: 1.0
To: pkix@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz> <1361195591.51223247ad553@mail.inbox.lv> <1F94BBCDF9E6E7438147ABA3C338441A01594CEA16@MX32A.corp.emc.com>
In-reply-to: <1F94BBCDF9E6E7438147ABA3C338441A01594CEA16@MX32A.corp.emc.com>
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7bit
Subject: Re: [pkix] purpose of LDAP in PKI
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: joel.kazin1@verizon.net
List-Id: PKIX Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2013 14:18:55 -0000

When an enterprise is issuing certificates to its employees and 
contractors there can be a need to make the encryption certificate 
publicly available for traffic from external parties to individuals at 
that enterprise.

Joel

On 2/18/2013 9:08 AM, Goulet, Walter wrote:
> Quoting Peter Gutmann :
> Andris Berzins  writes:
>
>>>> What could be the reason why end user certificates should be stored in LDAP
>>>> by the CA and made publicly available?
>>> There isn't one. It's (ancient) historical baggage based on X.509's origins
>>> in X.500, and some of the people writing the standards haven't realised yet
>>> that HTTP won.
>
>> When I apply for ID-card having authentication and qualified signature certificate on it,
>> I have to checkbox whether I want my certificates to be published in LDAP.
>> I get no clear answer how could I benefit from my certificates being published.
> In enterprise or other private PKI deployments publishing certificates to LDAP stores can be very useful for applications such as S/MIME where a sender's mail client can fetch a recipient's certificate from a centralized LDAP directory service. Basically, exposing your certificate via LDAP makes it *much* easier for other applications to actually use your certificate.
>
> The benefits of publishing your certificate publicly (i.e. over Internet accessible LDAP directory store) are less clear to me.
>
>
> Peter.
> _______________________________________________
> 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 pgut001@cs.auckland.ac.nz  Mon Feb 18 06:25:53 2013
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 296E621F8A2F for ; Mon, 18 Feb 2013 06:25:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.39
X-Spam-Level: 
X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209,  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 AXw6FhXGshES for ; Mon, 18 Feb 2013 06:25:51 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id C4A3A21F8A14 for ; Mon, 18 Feb 2013 06:25:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1361197551; x=1392733551; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=aSSrcb/JdsILHe9wMp7hOEuk6RfmyvbUIGTgZch3wGU=; b=YmtFlyVcFA7Pcf2b9a6RmXTAkaJk/LARirsh/43+jvFvVjbekdrjxbTc NBtR19ZtdeNUwpB17/PYfNNBDFHx/jap6IQ+afdV1eEV/pycohDoL1Nlp 4evp8LtVCQ2TlLAbtm0B4HgtAm+WgNVoAnW01WRX0kHAPdmrXVSmcO7TC o=;
X-IronPort-AV: E=Sophos;i="4.84,688,1355050800"; d="scan'208";a="170992683"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Feb 2013 03:25:50 +1300
Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe1.UoA.auckland.ac.nz (130.216.4.112) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 19 Feb 2013 03:25:49 +1300
Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.108]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 03:25:49 +1300
From: Peter Gutmann 
To: "pkix@ietf.org" 
Thread-Topic: [pkix] purpose of LDAP in PKI
Thread-Index: Ac4N49i4dhR1gCu+Q128RtNML6oc6A==
Date: Mon, 18 Feb 2013 14:25:48 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C733340DAA7@uxcn10-2.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] purpose of LDAP in PKI
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, 18 Feb 2013 14:25:53 -0000

"Goulet, Walter"  writes:=0A=
=0A=
>Basically, exposing your certificate via LDAP makes it *much* easier for=
=0A=
>other applications to actually use your certificate.=0A=
=0A=
This should really be:=0A=
=0A=
  Basically, exposing your certificate makes it *much* easier for other=0A=
  applications to actually use your certificate.=0A=
=0A=
The built-in assumption in the original statement that LDAP is the only way=
 to=0A=
do this is at best incorrect, at worst dangerous (it implies that you need =
to=0A=
LDAP-enable an application, configure and run an LDAP server, and get thing=
s=0A=
to talk LDAP to each other, which can be enough to sink a PKI project).=0A=
=0A=
Peter.=0A=

From era@x500.eu  Mon Feb 18 08:10:21 2013
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 309E821F8C09 for ; Mon, 18 Feb 2013 08:10:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.281
X-Spam-Level: 
X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HELO_EQ_DK=1.009, RCVD_IN_SORBS_WEB=0.619]
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 xeSwnufl5Qkb for ; Mon, 18 Feb 2013 08:10:20 -0800 (PST)
Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by ietfa.amsl.com (Postfix) with ESMTP id E5B6D21F8B90 for ; Mon, 18 Feb 2013 08:10:19 -0800 (PST)
Received: from ([62.44.134.108]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id DSC70016 for ; Mon, 18 Feb 2013 17:10:16 +0100
From: "Erik Andersen" 
To: 
References: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz>
Date: Mon, 18 Feb 2013 17:10:13 +0100
Message-ID: <003b01ce0df2$717801e0$546805a0$@eu>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
thread-index: Ac4N3T/yho4nk/8wRB68KSNUgoj19AAFEYRw
Content-Language: da
Subject: Re: [pkix] purpose of LDAP in PKI
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, 18 Feb 2013 16:10:21 -0000

Hi Peter

LDAP is a primarily an application protocol. HTTP is a communication
protocol. Comparing a application protocol with a communication protocol =
is
noncense. HTTP could in principle also be used to access a directory, =
such
as LDAP. Most X.500 implementation have a Web (HTTP) interface.

Erik

-----Oprindelig meddelelse-----
Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af =
Peter
Gutmann
Sendt: 18. februar 2013 14:39
Til: pkix@ietf.org
Emne: [pkix] purpose of LDAP in PKI

Andris Berzins  writes:

>What could be the reason why end user certificates should be stored in=20
>LDAP by the CA and made publicly available?

There isn't one.  It's (ancient) historical baggage based on X.509's =
origins
in X.500, and some of the people writing the standards haven't realised =
yet
that HTTP won.

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


From ferda.topcan@tubitak.gov.tr  Mon Feb 18 09:01:05 2013
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 4688621F8C3E for ; Mon, 18 Feb 2013 09:01:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.173
X-Spam-Level: *
X-Spam-Status: No, score=1.173 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_TR=0.935, RCVD_BAD_ID=2.837]
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 zq+y3TrKuzGp for ; Mon, 18 Feb 2013 09:01:03 -0800 (PST)
Received: from sg01.tubitak.gov.tr (mta.tubitak.gov.tr [193.140.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 330AC21F8C2D for ; Mon, 18 Feb 2013 09:01:02 -0800 (PST)
Received: (surgate 49709 invoked by uid 1001); 18 Feb 2013 17:00:55 -0000
Received: from unknown (HELO mta01.tubitak.gov.tr) (193.140.13.215) by 0 with SMTP; 18 Feb 2013 16:58:37 -0000
Received: from localhost (localhost [127.0.0.1])by mta01.tubitak.gov.tr (Postfix) with ESMTP id BF5A31E2FB7; Mon, 18 Feb 2013 17:02:45 +0200 (EET)
X-Virus-Scanned: amavisd-new at mta01.tubitak.gov.tr
Received: from mta01.tubitak.gov.tr ([127.0.0.1])by localhost (mta01.tubitak.gov.tr [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id qgHOl_qN9cww; Mon, 18 Feb 2013 17:02:44 +0200 (EET)
Received: by mta01.tubitak.gov.tr (Postfix, from userid 89)id 4C2FE1E2F08; Mon, 18 Feb 2013 16:57:44 +0200 (EET)
Received: from localhost (localhost [127.0.0.1])by mta01.tubitak.gov.tr (Postfix) with ESMTP id C78F81E340E; Mon, 18 Feb 2013 16:50:00 +0200 (EET)
X-Virus-Scanned: amavisd-new at mta01.tubitak.gov.tr
Received: from mta01.tubitak.gov.tr ([127.0.0.1])by localhost (mta01.tubitak.gov.tr [127.0.0.1]) (amavisd-new, port 10026)with ESMTP id yXtO0xR9gRvi; Mon, 18 Feb 2013 16:49:59 +0200 (EET)
Received: from mail02.tubitak.gov.tr (mail02.tubitak.gov.tr [10.250.10.220])by mta01.tubitak.gov.tr (Postfix) with ESMTP id B8AD61E350C; Mon, 18 Feb 2013 16:46:25 +0200 (EET)
From: Ferda Topcan 
To: "'Peter Gutmann'" ,
References: <9A043F3CF02CD34C8E74AC1594475C733340DAA7@uxcn10-2.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C733340DAA7@uxcn10-2.UoA.auckland.ac.nz>
Date: Mon, 18 Feb 2013 16:46:25 +0200 (EET)
Message-ID: <24ed668b.00000dc8.0000000c@UEKAE-PC>
MIME-Version: 1.0
Content-Type: text/plain;charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-Mailer: Zimbra 8.0.0_GA_5434 (ZimbraConnectorForOutlook/7.1.4.6356)
Thread-Index: Bd0cS1MKQAbF+8qJcIPU2MdLzU+3Ag==
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609
X-Originating-IP: [10.250.10.218]
Thread-Topic: purpose of LDAP in PKI
X-SMTP-Filter: SurGATE SMTP Filter EngineRelease 4.0 ($Revision: 523 $)
X-SurGATE-Result: Clean (Content eval: -10.00 points)
X-SurGATE-Reason: 
Subject: Re: [pkix] purpose of LDAP in PKI
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, 18 Feb 2013 17:01:05 -0000

Actually we do not need to publish signer certificate publicly. Because
signer certificate can be obtained from signature package as defined in
PKCS#7. 

But in case of mobile signature signer certificate needs to be published.
Because signer certificate is not available in SIM card. And signature
creation application needs the signer certificate before signing process
to construct the ESS-Signing-Certificate attribute. 

Ferda TOPCAN
................................................................

   

Disclaimer  

-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
Peter Gutmann
Sent: Monday, February 18, 2013 4:26 PM
To: pkix@ietf.org
Subject: Re: [pkix] purpose of LDAP in PKI

"Goulet, Walter"  writes:

>Basically, exposing your certificate via LDAP makes it *much* easier for
>other applications to actually use your certificate.

This should really be:

  Basically, exposing your certificate makes it *much* easier for other
  applications to actually use your certificate.

The built-in assumption in the original statement that LDAP is the only
way to
do this is at best incorrect, at worst dangerous (it implies that you need
to
LDAP-enable an application, configure and run an LDAP server, and get
things
to talk LDAP to each other, which can be enough to sink a PKI project).

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

From mstjohns@comcast.net  Mon Feb 18 09:12:45 2013
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 5CD8821F8AD4 for ; Mon, 18 Feb 2013 09:12:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.439
X-Spam-Level: 
X-Spam-Status: No, score=-99.439 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_43=0.6, MIME_QP_LONG_LINE=1.396,  RDNS_NONE=0.1, 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 gVlYcB26J4Dt for ; Mon, 18 Feb 2013 09:12:44 -0800 (PST)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id AAF9821F8AD8 for ; Mon, 18 Feb 2013 09:12:44 -0800 (PST)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id 1qez1l0041YDfWL5FtCk7R; Mon, 18 Feb 2013 17:12:44 +0000
Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta20.westchester.pa.mail.comcast.net with comcast id 1tCi1l00r2kB7pQ3gtCjkJ; Mon, 18 Feb 2013 17:12:44 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 18 Feb 2013 12:12:43 -0500
To: "Erik Andersen" ,
From: Michael StJohns 
In-Reply-To: <003b01ce0df2$717801e0$546805a0$@eu>
References: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz> <003b01ce0df2$717801e0$546805a0$@eu>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361207564; bh=9/LIH+f86yREhFZSYTzxxsmM0M46TTSJtzyoMymoktE=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=JOLyWSgnWPcDExuu1IqbcuE9UVujod5tXMsIwTICetI6SUwfqWI3PxDykHW/1eD9c ApEqSVptPcAAp8f0kep1Cjf9eVRuzqtiTZFMWuEDl5ji6B8aBAozjJI7Vgoee3QNKG 8PURyZhzKBV9OSR7gmSwrmWa+O38Df5KNk0IaInhJDxhuCpehC7FSExURTcx/kWaF3 YN148XePiqg7vVXiz3C5LkZhjr+3KdvWUy2WerSe1la1ELzYqNNcMgK0DBk0L4uIF7 EW3r/pcyHYSktWj2J9NqKEv91XNYLtBxnHeuPFA3jyWdAg8X9leqWPNpNz99jqJ+x9 ivVNR6Y1277kQ==
Message-Id: <20130218171244.AAF9821F8AD8@ietfa.amsl.com>
Subject: Re: [pkix] purpose of LDAP in PKI
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, 18 Feb 2013 17:12:45 -0000

At 11:10 AM 2/18/2013, Erik Andersen wrote:
>Hi Peter
>
>LDAP is a primarily an application protocol. HTTP is a communication
>protocol.=20

Um... =20

HTTP runs directly over TCP
LDAP runs directly over TCP

HTTP can be used to query for data.
LDAP can be used to query for data

HTTP can be used to store data
LDAP can be used to store data

HTTP can return data in multiple formats (HTML, octet streams, etc)
LDAP can return data in multiple formats=20

 From a protocol point of view, the two have pretty similar data=
 store/retrieval mechanism.  It's when you get to the server side that=
 things get interesting.  For example, it's perfectly possible to build web=
 pages of nothing but "ldap:" links and access them from a browser - where=
 the contents of the ldap store are say HTML web pages.   It's also=
 perfectly possible to build an HTTP web server that serves up nothing but=
 ldap'ish data blobs.  That doesn't change the protocol.

So I reject your reality and substitute my own.  They really are both=
 application protocols.:-)=20


>Comparing a application protocol with a communication protocol is
>noncense. HTTP could in principle also be used to access a directory, such
>as LDAP.=20

Yup - this is usually hidden though in the machinations of the web server=
 rather than being a direct mapping.  But it's really not a protocol=
 difference, but a difference in how the server you're talking to interprets=
 the query.   (E.g. yes, the semantics of LDAP and HTTP are different, but=
 they accomplish almost the same thing with HTTP being a bit more=
 extensible).

Mike


>Most X.500 implementation have a Web (HTTP) interface.
>
>Erik
>
>-----Oprindelig meddelelse-----
>Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af=
 Peter
>Gutmann
>Sendt: 18. februar 2013 14:39
>Til: pkix@ietf.org
>Emne: [pkix] purpose of LDAP in PKI
>
>Andris Berzins  writes:
>
>>What could be the reason why end user certificates should be stored in=20
>>LDAP by the CA and made publicly available?
>
>There isn't one.  It's (ancient) historical baggage based on X.509's=
 origins
>in X.500, and some of the people writing the standards haven't realised yet
>that HTTP won.
>
>Peter.
>_______________________________________________
>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 piyush@ditenity.com  Mon Feb 18 10:07:59 2013
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 EB24021F86A3 for ; Mon, 18 Feb 2013 10:07:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.551
X-Spam-Level: 
X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.047,  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 b0zFQxmZd4Un for ; Mon, 18 Feb 2013 10:07:59 -0800 (PST)
Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8710021F853E for ; Mon, 18 Feb 2013 10:07:54 -0800 (PST)
Received: by mail-gh0-f182.google.com with SMTP id z15so622827ghb.27 for ; Mon, 18 Feb 2013 10:07:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=ukifLp/ILRH/dBjFEPhT3YerMRDDR+EaZGP737oGTPo=; b=DfnJ/JkMG9sRbEbqgeGn5kd2KTq9DTEm1X8REJOihqcKe0TE1T6IIJXY+dKMBQAtaD LcRFa9KJ+CYKu9BYwXkvrWg2TwmAhF514tAhTshSwTi1znXotMTKZ/oDAIMlpswhvxEM l8vmJvo5Dhv2AZ5RtwIag7J6b/R5gU53ZMv2JgjXb32P6gtYr6YP2ZmdATfpCsvPLNe9 I9ngUdlHFEfzgeBGV6G6fJymTaotMtbvjMZfpiC9MlP8ra+1M3fnkcisjH1MN0VOGBpb Nt71oiT5j3P8D2+bxOv9UDzWAF2ID50Yh8TIbMJ/XNfs4FdIrE3uqgbHeY+CA2zMcxuq VEqg==
X-Received: by 10.236.180.42 with SMTP id i30mr21918838yhm.68.1361210873963; Mon, 18 Feb 2013 10:07:53 -0800 (PST)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id i24sm63763855ann.16.2013.02.18.10.07.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 Feb 2013 10:07:53 -0800 (PST)
From: "Piyush Jain" 
To: "'Andris Berzins'" , 
References: <1361191787.5122236bed12c@mail.inbox.lv>
In-Reply-To: <1361191787.5122236bed12c@mail.inbox.lv>
Date: Mon, 18 Feb 2013 10:07:46 -0800
Message-ID: <026b01ce0e02$dc1fd440$945f7cc0$@ditenity.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_026C_01CE0DBF.CE040E50"
X-Mailer: Microsoft Outlook 14.0
thread-index: AQEicwPZT3fKZDi3TxWvDDx1D/SpDpnXGv3w
Content-Language: en-us
X-Gm-Message-State: ALoCoQk48heIB3sR/FlogaFJ+DaNXzSeRGvs+OenQDc09JjpbdTOFyyAzbRkKQV1DoWQ/5nzPh6/
Subject: Re: [pkix] purpose of LDAP in PKI
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, 18 Feb 2013 18:08:00 -0000

This is a multipart message in MIME format.

------=_NextPart_000_026C_01CE0DBF.CE040E50
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=20

Why make user certificate publicly available?

-          Others can look you up and encrypt stuff that the send you =
without asking you for your certificate.

Why Not?

-          Loss of privacy

=20

Why use ldap?

-          Historical reasons.=20

-          Standard schema/attributes exist to store such information

Why not?

-          Scalability issues, complicated setup, difficult to find LDAP =
experts, subtle differences/idiosyncrasies of ldap implementations make =
interoperability difficult.

=20

Why use http?

-          Everyone knows http J, scalable

Why not?

-          Standards to store/search for certificates/CRLs in HTTP =
stores are relatively new and implementations are limited. This is =
changing though and many big PKI implementations use HTTP to store CA =
certificates and CRLs. Have not seen any stores http backend that stores =
user certificates and provides API to search for such  certificates.

=20

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of =
Andris Berzins
Sent: Monday, February 18, 2013 4:50 AM
To: pkix@ietf.org
Subject: [pkix] purpose of LDAP in PKI

=20

=20

=20

=20

Hello,

What could be the reason why end user certificates should be stored in =
LDAP by the CA and made publicly available?


(I might understand the reason for storing CRLs (LDAP as an alternative =
to HTTP).)=20


------=_NextPart_000_026C_01CE0DBF.CE040E50
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


 
Why make user certificate publicly available?
-          =
Others can look you up and encrypt stuff that the send you without =
asking you for your certificate.
Why Not?
-          =
Loss of privacy
 
Why use ldap?
-          =
Historical reasons. 
-          =
Standard schema/attributes exist to store such =
information
Why not?
-          =
Scalability issues, complicated setup, difficult to find LDAP =
experts, subtle differences/idiosyncrasies of ldap implementations make =
interoperability difficult.
 
Why use http?
-          =
Everyone knows http J, scalable
Why not?
-          =
Standards to store/search for certificates/CRLs in HTTP stores are =
relatively new and implementations are limited. This is changing though =
and many big PKI implementations use HTTP to store CA certificates and =
CRLs. Have not seen any stores http backend that stores user =
certificates and provides API to search for such =
=C2=A0certificates.
 
From:=
 =
pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of =
Andris Berzins
Sent: Monday, February 18, 2013 4:50 =
AM
To: pkix@ietf.org
Subject: [pkix] purpose of LDAP =
in PKI
 
 
 
 
Hello,

What could be the reason why end user =
certificates should be stored in LDAP by the CA and made publicly =
available?


(I might understand the reason for storing CRLs =
(LDAP as an alternative to HTTP).) =


------=_NextPart_000_026C_01CE0DBF.CE040E50--


From pgut001@cs.auckland.ac.nz  Mon Feb 18 20:23:24 2013
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 66C9621E8040 for ; Mon, 18 Feb 2013 20:23:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201,  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 JEa1GCHtLL-S for ; Mon, 18 Feb 2013 20:23:23 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id AF23121E8082 for ; Mon, 18 Feb 2013 20:23:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1361247802; x=1392783802; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=EE4l6cGJB2PjxWSUbgQCKOu5AwezHfbxxqQSm5Xg/wA=; b=chSWWhIfDTg4wby8TOdoP71OfZGWzn9Y2YqjzIDe1FsLfxFMJ2xeqM1t Z5Iz+4ijzwLrCLvrGJxr0zYvbkisOOlVK5kFay73haozGcrBAVio9U3oz eWvu4GmOXA/AY5C2rNlBPHaS3f4mC63HFvH2TNu9sImIEfRBuauWndB8n I=;
X-IronPort-AV: E=Sophos;i="4.84,692,1355050800"; d="scan'208";a="171130418"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Feb 2013 17:23:20 +1300
Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 19 Feb 2013 17:23:19 +1300
Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.108]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 17:23:19 +1300
From: Peter Gutmann 
To: IETF PKIX 
Thread-Topic: [pkix] purpose of LDAP in PKI
Thread-Index: Ac4OWNgZTCn1la7XQtO64mLPzQM+Lg==
Date: Tue, 19 Feb 2013 04:23:18 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C733340E0E6@uxcn10-2.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] purpose of LDAP in PKI
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, 19 Feb 2013 04:23:24 -0000

Erik Andersen  writes:=0A=
=0A=
>LDAP is a primarily an application protocol. HTTP is a communication=0A=
>protocol. Comparing a application protocol with a communication protocol i=
s=0A=
>noncense. HTTP could in principle also be used to access a directory, such=
 as=0A=
>LDAP.=0A=
=0A=
Your statement is based on the incorrect premise that I (or users in genera=
l)=0A=
want an X.500 directory.  As I mentioned earlier, HTTP won, everything else=
=0A=
(and in particular X.500) lost, so the comparison isn't between a=0A=
communication protocol and an application protocol but a universally-availa=
ble=0A=
solution and a failed one.=0A=
=0A=
(Gawd, I'm starting to sound like Phil H-B :-).=0A=
=0A=
Peter.=0A=

From DPKemp@missi.ncsc.mil  Tue Feb 19 06:26:16 2013
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 DECDB21F8DC1 for ; Tue, 19 Feb 2013 06:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 sFMB+h3qhx42 for ; Tue, 19 Feb 2013 06:26:16 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id CA41C21F8A25 for ; Tue, 19 Feb 2013 06:26:15 -0800 (PST)
Received: from clavin.missi.ncsc.mil (squid.missi.ncsc.mil [144.51.60.169]) by stingray.missi.ncsc.mil with ESMTP id r1JEQDkt071701 for ; Tue, 19 Feb 2013 09:26:14 -0500 (EST)
Received: from clavin.missi.ncsc.mil ([169.254.1.7]) by SQUID.missi.ncsc.mil ([fe80::e032:d4c7:c51f:85ec%14]) with mapi id 14.02.0328.009; Tue, 19 Feb 2013 09:25:24 -0500
From: "Kemp, David P." 
To: "pkix@ietf.org" 
Thread-Topic: [pkix] purpose of LDAP in PKI
Thread-Index: AQHODfJjrwPsnJVCEUWwGUttw4fWuJiALkCAgAEJgxA=
Date: Tue, 19 Feb 2013 14:25:25 +0000
Message-ID: <5B1D7E570380A64989D4C069F7D14BC868A058D4@clavin.missi.ncsc.mil>
References: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz> <003b01ce0df2$717801e0$546805a0$@eu> <20130218171244.AAF9821F8AD8@ietfa.amsl.com>
In-Reply-To: <20130218171244.AAF9821F8AD8@ietfa.amsl.com>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] purpose of LDAP in PKI
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, 19 Feb 2013 14:26:17 -0000

Mike,

That misses the point.  LDAP defines an application protocol that supports =
transactions with known semantics, allowing M2M communications based on pub=
lished standards rather than bespoke specifications.   HTTP does not define=
 application semantics -- HTML, SOAP, REST, etc perform that function in th=
e HTTP space.

It would be trivial to specify certificate search, retrieval, update transa=
ctions over HTTP, but the set of such transactions has not been standardize=
d.  Every Internet-connected device has a DNS resolver that allows machines=
 to manage and exchange resource data without human intervention.  Certific=
ates could be managed as DNS resources (in theory - there is resistance to =
that idea in practice) using only TCP/UDP and the published DNS specs.  LDA=
P can do that with just the published TCP and LDAP specs. =20

If a set of DNS-over-HTTP or directory-over-HTTP transactions were defined,=
 HTTP could support M2M management and distribution of DNS and certificate =
resources.  But those transactions aren't standardized, so HTTP alone canno=
t be considered an "application protocol" with respect to DNS resources, SQ=
L databases, or directories.

Dave


-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mic=
hael StJohns
Sent: Monday, February 18, 2013 12:13 PM
To: Erik Andersen; pkix@ietf.org
Subject: Re: [pkix] purpose of LDAP in PKI

At 11:10 AM 2/18/2013, Erik Andersen wrote:
>Hi Peter
>
>LDAP is a primarily an application protocol. HTTP is a communication=20
>protocol.

Um... =20

HTTP runs directly over TCP
LDAP runs directly over TCP

HTTP can be used to query for data.
LDAP can be used to query for data

HTTP can be used to store data
LDAP can be used to store data

HTTP can return data in multiple formats (HTML, octet streams, etc) LDAP ca=
n return data in multiple formats=20

 From a protocol point of view, the two have pretty similar data store/retr=
ieval mechanism.  It's when you get to the server side that things get inte=
resting.  For example, it's perfectly possible to build web pages of nothin=
g but "ldap:" links and access them from a browser - where the contents of =
the ldap store are say HTML web pages.   It's also perfectly possible to bu=
ild an HTTP web server that serves up nothing but ldap'ish data blobs.  Tha=
t doesn't change the protocol.

So I reject your reality and substitute my own.  They really are both appli=
cation protocols.:-)=20


>Comparing a application protocol with a communication protocol is=20
>noncense. HTTP could in principle also be used to access a directory,=20
>such as LDAP.

Yup - this is usually hidden though in the machinations of the web server r=
ather than being a direct mapping.  But it's really not a protocol differen=
ce, but a difference in how the server you're talking to interprets the que=
ry.   (E.g. yes, the semantics of LDAP and HTTP are different, but they acc=
omplish almost the same thing with HTTP being a bit more extensible).

Mike


>Most X.500 implementation have a Web (HTTP) interface.
>
>Erik
>
>-----Oprindelig meddelelse-----
>Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af=20
>Peter Gutmann
>Sendt: 18. februar 2013 14:39
>Til: pkix@ietf.org
>Emne: [pkix] purpose of LDAP in PKI
>
>Andris Berzins  writes:
>
>>What could be the reason why end user certificates should be stored in=20
>>LDAP by the CA and made publicly available?
>
>There isn't one.  It's (ancient) historical baggage based on X.509's=20
>origins in X.500, and some of the people writing the standards haven't=20
>realised yet that HTTP won.
>
>Peter.
>_______________________________________________
>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


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

From paul.hoffman@vpnc.org  Tue Feb 19 07:16:19 2013
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 671C321F8DF8 for ; Tue, 19 Feb 2013 07:16:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.591
X-Spam-Level: 
X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 k2x8eywazwtr for ; Tue, 19 Feb 2013 07:16:18 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AB84121F8DF0 for ; Tue, 19 Feb 2013 07:16:17 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1JFGEMj034528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Feb 2013 08:16:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman 
In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC868A058D4@clavin.missi.ncsc.mil>
Date: Tue, 19 Feb 2013 07:16:15 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <2555EA5F-E28F-404A-A9F9-074ACBAEE78E@vpnc.org>
References: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz> <003b01ce0df2$717801e0$546805a0$@eu> <20130218171244.AAF9821F8AD8@ietfa.amsl.com> <5B1D7E570380A64989D4C069F7D14BC868A058D4@clavin.missi.ncsc.mil>
To: "Kemp, David P." 
X-Mailer: Apple Mail (2.1499)
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] purpose of LDAP in PKI
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, 19 Feb 2013 15:16:19 -0000

On Feb 19, 2013, at 6:25 AM, "Kemp, David P."  =
wrote:

> That misses the point.  LDAP defines an application protocol that =
supports transactions with known semantics, allowing M2M communications =
based on published standards rather than bespoke specifications.   HTTP =
does not define application semantics -- HTML, SOAP, REST, etc perform =
that function in the HTTP space.
>=20
> It would be trivial to specify certificate search, retrieval, update =
transactions over HTTP, but the set of such transactions has not been =
standardized.

*cough* RFC 2585 *cough* (To be honest, I wouldn't have remembered it =
unless I had be co-author.)

>  Every Internet-connected device has a DNS resolver that allows =
machines to manage and exchange resource data without human =
intervention.  Certificates could be managed as DNS resources (in theory =
- there is resistance to that idea in practice) using only TCP/UDP and =
the published DNS specs.  LDAP can do that with just the published TCP =
and LDAP specs. =20
>=20
> If a set of DNS-over-HTTP or directory-over-HTTP transactions were =
defined, HTTP could support M2M management and distribution of DNS and =
certificate resources.  But those transactions aren't standardized, so =
HTTP alone cannot be considered an "application protocol" with respect =
to DNS resources, SQL databases, or directories.

What is not specified is a single URL patter to find a particular =
certificate.

--Paul Hoffman=

From piyush@ditenity.com  Tue Feb 19 08:13:40 2013
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 70F2521F8D72 for ; Tue, 19 Feb 2013 08:13:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.554
X-Spam-Level: 
X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.044,  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 LZb0-yugINzN for ; Tue, 19 Feb 2013 08:13:38 -0800 (PST)
Received: from mail-gh0-f175.google.com (mail-gh0-f175.google.com [209.85.160.175]) by ietfa.amsl.com (Postfix) with ESMTP id F0ACA21F8D31 for ; Tue, 19 Feb 2013 08:13:37 -0800 (PST)
Received: by mail-gh0-f175.google.com with SMTP id g18so811688ghb.34 for ; Tue, 19 Feb 2013 08:13:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=8qgmO0/iXd0W+D2noY3nktFvnF9A1zCESIGAUUgxjrU=; b=k8/K7xtcFJNR+dKioNd3ZgEuR59TbO+j5ueYK0pbt2j7KYV/lZv9atDDvnn1INiUkf B8Eqi+njuydA016KMzxpKPqvu6k5GPQrsq5I3zkdhG1vLEoRvLUPxxYw46jcCFhd4t1e K4jE+OfRH6q5Z7UiWCFx+VDgqjEARHz2WKKxjt156MCJ7WDWDdYasZyfnXabfI+WcjCT SoOjH1CYIsJgHAwQhNtMhvB6fiV4Y8zMR5HFNaWqy3Hbx1239xj1FqyH/rC1dtAN5XjC 5JZ0ibzPQubz0fKjhJGAG18tH55m2NlDB8DZWqq9+XttFI65CmsACOvVp0VCe+BtYZMU ou9A==
X-Received: by 10.236.129.72 with SMTP id g48mr29802320yhi.102.1361290415818;  Tue, 19 Feb 2013 08:13:35 -0800 (PST)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id s74sm18116044yhh.5.2013.02.19.08.13.34 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Feb 2013 08:13:35 -0800 (PST)
From: "Piyush Jain" 
To: "'Paul Hoffman'" , "'Kemp, David P.'" 
References: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz> <003b01ce0df2$717801e0$546805a0$@eu> <20130218171244.AAF9821F8AD8@ietfa.amsl.com> <5B1D7E570380A64989D4C069F7D14BC868A058D4@clavin.missi.ncsc.mil> <2555EA5F-E28F-404A-A9F9-074ACBAEE78E@vpnc.org>
In-Reply-To: <2555EA5F-E28F-404A-A9F9-074ACBAEE78E@vpnc.org>
Date: Tue, 19 Feb 2013 08:13:28 -0800
Message-ID: <039901ce0ebc$0e82b290$2b8817b0$@ditenity.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
thread-index: AQHj1NZDIeSwlxp7fsukEvSxjfgwkQHAXzCNAmmMXo0BKI7LJQFBPO8kmCEurDA=
Content-Language: en-us
X-Gm-Message-State: ALoCoQk1ACN+8MYyMsGxYbpeXjcDnzJxuzavEbPlg03yD0kf8kXIgsjyHTx9WMfoATjvOSg3nZkl
Cc: pkix@ietf.org
Subject: Re: [pkix] purpose of LDAP in PKI
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, 19 Feb 2013 16:13:40 -0000

> *cough* RFC 2585 *cough* (To be honest, I wouldn't have remembered it
> unless I had be co-author.)
> 
 :)

> What is not specified is a single URL patter to find a particular
certificate.
>

http://www.rfc-editor.org/rfc/rfc4387.txt authored by our own Dr. Peter
Gutmann.

 


From denis.pinkas@bull.net  Tue Feb 19 08:49:27 2013
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 2511921F8D0B for ; Tue, 19 Feb 2013 08:49:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Level: 
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 U767oN2IbSG9 for ; Tue, 19 Feb 2013 08:49:21 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0A34821F8E01 for ; Tue, 19 Feb 2013 08:49:21 -0800 (PST)
Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 2483E1D247; Tue, 19 Feb 2013 17:49:20 +0100 (CET)
Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2013021917491916-40696 ; Tue, 19 Feb 2013 17:49:19 +0100 
Message-ID: <5123AD0B.4050709@bull.net>
Date: Tue, 19 Feb 2013 17:49:15 +0100
From: Denis Pinkas 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: pkix 
X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 19/02/2013 17:49:19, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 19/02/2013 17:49:20, Serialize complete at 19/02/2013 17:49:20
Content-Type: multipart/alternative; boundary="------------050608020508000407000500"
Subject: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 19 Feb 2013 16:49:27 -0000

This is a multi-part message in MIME format.
--------------050608020508000407000500
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


  Mozilla's CA Certificate Policy Version 2.1 is available at:
  http://www.mozilla.org/projects/security/certs/policy/

Clause 9 of the Mozilla CA Certificate Inclusion Policy (available
at**http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html) 
states:**

9.We encourage CAs to technically constrain all subordinate CA 
certificates. For a certificate to be considered *
technically constrained,* the certificate MUST include an Extended Key 
Usage (EKU) 
extension specifying
all extended key usages that the subordinate CA is authorized to issue 
certificates for.
The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension.

*
The above link points to : 
*http://tools.ietf.org/html/rfc5280#section-4.2.1.12

*4.2.1.12**.Extended 
Key Usage***

**

*This extension indicates one or more purposes for which the certified*

*public key may be used, in addition to or in place of the basic*

*purposes indicated in the key usage extension.In general, this*

*extension will appear only in end entity certificates. This*

*extension is defined as follows:*

**

***id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }*

**

***ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId*

**

*KeyPurposeId ::= OBJECT IDENTIFIER*

**

*Key purposes may be defined by any organization with a need.Object*

*identifiers used to identify key purposes MUST be assigned in*

*accordance with IANA or ITU-T Recommendation X.660 [X.660].*

**

*This extension MAY, at the option of the certificate issuer, be*

*either critical or non-critical.*

**

*If the extension is present, then the certificate MUST only be used*

*for one of the purposes indicated.If multiple purposes are*

*indicated the application need not recognize all purposes indicated,*

*as long as the intended purpose is present.Certificate using*

*applications MAY require that the extended key usage extension be*

*present and that a particular purpose be indicated in order for the*

*certificate to be acceptable to that application.*

**

*If a CA includes extended key usages to satisfy such applications,*

*but does not wish to restrict usages of the key, the CA can include*

*the special KeyPurposeId anyExtendedKeyUsage in addition to the*

*particular key purposes required by the applications.Conforming CAs*

*SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage*

*KeyPurposeId is present.Applications that require the presence of a*

*particular purpose MAY reject certificates that include the*

*anyExtendedKeyUsage OID but not the particular OID expected for the*

*application.*

**

*If a certificate contains both a key usage extension and an extended*

*key usage extension, then both extensions MUST be processed*

*independently and the certificate MUST only be used for a purpose*

*consistent with both extensions.If there is no purpose consistent*

*with both extensions, then the certificate MUST NOT be used for any*

*purpose.*

**

IMO, the semantics of the EKU extension, as defined in RFC 5280 and in 
X.509, does not allow using
that extension in the way which is described in this document.

I have informed Mozilla (certificates@mozilla.org  ) of the issue and the answer was a pointer to a FAQ,
whichincludes the following statement*  (*https://wiki.mozilla.org/CA:CertificatePolicyV2.1).


    Frequently Asked Questions

 1. RFC 5280  reads "In general,
    this extension will appear only in end entity certificates".
    Is it non-standard to have EKU in intermediate certificates, and
    will client software break when receiving such a certificate chain?
      * Inclusion of EKU in CA certificates is generally allowed. NSS
        and CryptoAPI both treat the EKU extension in intermediate
        certificates
        as a constraint on the permitted EKU OIDs in end-entity
        certificates. Browsers and certificate client software have been
        using EKU
        in intermediate certificates, and it has been common for
        enterprise subordinate CAs in Windows environments to use EKU in
        their
        intermediate certificates to constrain certificate issuance.
        Therefore, it is unlikely that using EKU in intermediate
        certificates would
        break other client software.
      * The use of the EKU extension in intermediate certificates was
        discussed at length in the mozilla.dev.security.policy forum.
        

        We considered other options, such as standardizing a set of
        Policy OIDs or un-deprecating NetscapeCertType. The discussion
        included
        the concern that one interpretation of RFC 5280
         is that this use of EKU is
        non-standard, but it was decided that the RFCs are not clear,
        and perhaps conflicting, in regards to EKUs in CA certificates.
        In the discussion it was pointed out that other major browsers
        and client
        software already support this use of EKU but do not recognize
        NetscapeCertType; and we also recognized the difficulties
        involved in
        standardizing a set of Policy OIDs. The conclusion of the
        discussion was that EKU is the best tool for technically
        constraining the types
        of certificates that an intermediate certificate may sign.

The OID for EKU is the following: {joint-iso-itu-t(2) ds(5) 
certificateExtension(29) extKeyUsage(37)}

http://www.oid-info.com/get/2.5.29.37indicates:

"This field indicates one or more purposes for which the certified 
public key may be used, in addition to or in place of the basic purposes 
indicated
in the key usage extension field.

More information can be found in Recommendation ITU-T X.509 (March 2000) 
and 
in ISO/IEC 9594-8 (2001) 
: "Directory: 
Public-key and attribute
certificate frameworks".


The text from the last available recommendation ITU-X.509 is as follows:

"8.2.2.4 Extended key usage extension

This field indicates one or more purposes for which the certified public 
key may be used, in addition to or in place of the basic purposes
indicated in the key usage extension field. This field is defined as 
follows:

*extKeyUsage EXTENSION ::= {*

*SYNTAX SEQUENCE SIZE (1..MAX) OF KeyPurposeId*

*IDENTIFIED BY id-ce-extKeyUsage }*

*KeyPurposeId ::= OBJECT IDENTIFIER*

A CA may assert any-extended-key-usage by using the anyExtendedKeyUsage 
identifier. This enables a CA to issue a certificate
that contains OIDs for extended key usages that may be required by 
certificate-using applications, without restricting the certificate
to only those key usages. If extended key usage would restrict key 
usage, then the inclusion of this OID removes that restriction.

*anyExtendedKeyUsage OBJECT IDENTIFIER ::= { 2 5 29 37 0 }[S9]*

Key purposes may be defined by any organization with a need. Object 
identifiers used to identify key purposes shall be assigned
in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.

This extension may, at the option of the certificate issuer, be either 
critical or non-critical.

If the extension is flagged critical, then the certificate shall be used 
only for one of the purposes indicated.

If the extension is flagged non-critical, then it indicates the intended 
purpose or purposes of the key, and may be used in finding
the correct key/certificate of an entity that has multiple 
keys/certificates. If this extension is present, and the 
certificate-using system
recognizes and processes the extendedKeyUsage extension type, then the 
certificate-using system shall ensure that the certificate
shall be used only for one of the purposes indicated. (Using 
applications may nevertheless require that a particular purpose be 
indicated
in order for the certificate to be acceptable to that application.)

If a certificate contains both a critical key usage field and a critical 
extended key usage field, then both fields shall be processed i
ndependently and the certificate shall only be used for a purpose 
consistent with both fields. If there is no purpose consistent with both 
fields,
then the certificate shall not be used for any purpose".

Mozilla announces on 
https://lists.mozilla.org/listinfo/dev-security-policy: "/The 
subscribers list is only available to the list administrator". /
So it is quite hard to know who was on the discussion list and thus who 
participated to the discussion.

Since the publication is recent (February 14, 2013), it might be 
appropriate to ask to the Mozilla community to respect the compliance
to the standards. In order to fulfil its needs, the Mozilla community 
should:

-either define its own extension,

-or, propose a new extension so that it can be published in an RFC 
according to the IETF rules.

Any thoughts ?

Denis


--------------050608020508000407000500
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=ISO-8859-1


  

    
  
  
    
    
Mozilla's CA Certificate Policy Version 2.1 is
          available at: http://www.mozilla.org/projects/security/certs/policy/

    
Clause 9 of the
        Mozilla CA Certificate
        Inclusion Policy (available 

        at http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html)
        states:

    
9.   We encourage CAs to technically constrain all
        subordinate CA
        certificates. For a certificate to be considered 

          technically constrained,
        the certificate MUST include an Extended
          Key Usage
          (EKU) extension specifying 

        all extended key usages that the subordinate CA
        is authorized to issue certificates for. 

        The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this
        extension. 

    


          The
          above link points to : http://tools.ietf.org/html/rfc5280#section-4.2.1.12

        

        

    
  4.2.1.12.  Extended
          Key Usage

    
 

    
   This extension indicates
          one or more
          purposes for which the certified

    
   public key may be used,
          in addition to or in
          place of the basic

    
   purposes indicated in
          the key usage
          extension.  In general,
          this

    
   extension will appear
          only in end entity
          certificates.  This

    
   extension is defined as
          follows:

    
 

    
   id-ce-extKeyUsage
          OBJECT IDENTIFIER ::= { id-ce 37 }

    
 

    
   ExtKeyUsageSyntax ::= SEQUENCE
          SIZE (1..MAX) OF
          KeyPurposeId

    
 

    
   KeyPurposeId ::= OBJECT
          IDENTIFIER

    
 

    
   Key purposes may be
          defined by any
          organization with a need.  Object

    
  
          identifiers used to identify key purposes MUST be
          assigned in

    
   accordance with IANA or
          ITU-T Recommendation
          X.660 [X.660].

    
 

    
   This extension MAY, at
          the option of the
          certificate issuer, be

    
   either critical or
          non-critical.

    
 

    
   If the extension is
          present, then the
          certificate MUST only be used

    
   for one of the purposes
          indicated.  If multiple
          purposes are

    
   indicated the
          application need not recognize
          all purposes indicated,

    
   as long as the intended
          purpose is
          present.  Certificate
          using

    
   applications MAY require
          that the extended
          key usage extension be

    
   present and that a
          particular purpose be
          indicated in order for the

    
   certificate to be
          acceptable to that
          application.

    
 

    
   If a CA includes
          extended key usages to
          satisfy such applications,

    
   but does not wish to
          restrict usages of the
          key, the CA can include

    
   the special KeyPurposeId
          anyExtendedKeyUsage
          in addition to the

    
   particular key purposes
          required by the
          applications.  Conforming
          CAs

    
   SHOULD NOT mark this
          extension as critical
          if the anyExtendedKeyUsage

    
   KeyPurposeId is present.  Applications that require
          the presence of a

    
   particular purpose MAY
          reject certificates
          that include the

    
   anyExtendedKeyUsage OID
          but not the
          particular OID expected for the

    
   application.

    
 

    
   If a certificate
          contains both a key usage
          extension and an extended

    
   key usage extension,
          then both extensions
          MUST be processed

    
   independently and the
          certificate MUST only
          be used for a purpose

    
   consistent with both
          extensions.  If there
          is no purpose consistent

    
   with both extensions,
          then the certificate
          MUST NOT be used for any

    
   purpose.

    
 

    
IMO, the semantics
        of the EKU extension, as
        defined in RFC 5280 and in X.509, does not allow using 

        that extension in the
        way which is described in this document. 

    
 

    
I have informed Mozilla (certificates@mozilla.org) of the issue and the answer was a pointer to a FAQ, 
which includes the following statement (https://wiki.mozilla.org/CA:CertificatePolicyV2.1).

    
Frequently
          Asked Questions 

    
    
      
  1. RFC 5280 reads
          "In general, this extension will appear only in end entity
          certificates". 
    
          Is it non-standard to have EKU in intermediate certificates,
          and will client software break when receiving such a
          certificate chain? 
    2. 
      
      
        
    • Inclusion of EKU in CA
            certificates is generally allowed. NSS and CryptoAPI both
            treat the EKU extension in intermediate certificates 
      
            as a constraint on the permitted EKU OIDs in end-entity
            certificates. Browsers and certificate client software have
            been using EKU 
      
            in intermediate certificates, and it has been common for
            enterprise subordinate CAs in Windows environments to use
            EKU in their 
      
            intermediate certificates to constrain certificate issuance.
            Therefore, it is unlikely that using EKU in intermediate
            certificates would 
      
            break other client software. 
      • 
        
    • The use of the EKU extension
            in intermediate certificates was discussed at length in the
            mozilla.dev.security.policy

              forum. 
      
            We considered other options, such as standardizing a set of
            Policy OIDs or un-deprecating NetscapeCertType. The
            discussion included 
      
            the concern that one interpretation of RFC 5280 is
            that this use of EKU is non-standard, but it was
              decided that the RFCs are not clear, 
      
              and perhaps conflicting, in regards to EKUs in CA
              certificates      . In the discussion it was pointed out
            that other major browsers and client 
      
            software already support this use of EKU but do not
            recognize NetscapeCertType; and we also recognized the
            difficulties involved in 
      
            standardizing a set of Policy OIDs. The conclusion of the
            discussion was that EKU is the best tool for technically
            constraining the types 
      
            of certificates that an intermediate certificate may sign. 
      • 
      
    
    

    
 

    
The OID for EKU is the
        following: {joint-iso-itu-t(2)
ds(5)
        certificateExtension(29) extKeyUsage(37)}

    
http://www.oid-info.com/get/2.5.29.37
        indicates:

    
“This
        field indicates one or more
        purposes for which the certified public key may be used, in
        addition to or in
        place of the basic purposes indicated 

        in the key usage extension field.

        

        More information can be found in Recommendation
            ITU-T X.509 (March
            2000) and in ISO/IEC 9594-8
            (2001):
        "Directory: Public-key and attribute 

        certificate frameworks".

    

    
    
The
        text from the last available
        recommendation ITU-X.509 is as follows:

    
“ 
        8.2.2.4 Extended key usage extension

    
This
        field indicates one or more purposes
        for which the certified public key may be used, in addition to
        or in place of
        the basic purposes 

        indicated in the key usage extension field. This field is
        defined as follows:

    
extKeyUsage EXTENSION
          ::= {

    
SYNTAX SEQUENCE SIZE
          (1..MAX) OF KeyPurposeId

    
IDENTIFIED BY
          id-ce-extKeyUsage }

    
KeyPurposeId ::= OBJECT
          IDENTIFIER

    
A CA
        may assert
        any-extended-key-usage by using the anyExtendedKeyUsage
        identifier. This
        enables a CA to issue a certificate 

        that contains OIDs for extended key usages
        that may be required by certificate-using applications, without
        restricting the
        certificate 

        to only those key usages. If extended key usage would restrict
        key
        usage, then the inclusion of this OID removes that restriction.

    
anyExtendedKeyUsage
          OBJECT IDENTIFIER ::= { 2 5 29 37
          0 }[S9]

    
Key
        purposes may be defined by any
        organization with a need. Object identifiers used to identify
        key purposes
        shall be assigned 

        in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.

    
This
        extension may, at the option
        of the certificate issuer, be either critical or non-critical.

    
If the
        extension is flagged
        critical, then the certificate shall be used only for one of the
        purposes
        indicated.

    
If the
        extension is flagged
        non-critical, then it indicates the intended purpose or purposes
        of the key,
        and may be used in finding 

        the correct key/certificate of an entity that has
        multiple keys/certificates. If this extension is present, and
        the
        certificate-using system 

        recognizes and processes the extendedKeyUsage
        extension type, then the certificate-using system shall ensure
        that the
        certificate 

        shall be used only for one of the purposes indicated. (Using
        applications may nevertheless require that a particular purpose
        be indicated 

        in
        order for the certificate to be acceptable to that application.)

    
If a
        certificate contains both a
        critical key usage field and a critical extended key usage
        field, then both
        fields shall be processed i

        ndependently and the certificate shall only be used
        for a purpose consistent with both fields. If there is no
        purpose consistent with
        both fields, 

        then the certificate shall not be used for any purpose”.

    
 

    
Mozilla announces on https://lists.mozilla.org/listinfo/dev-security-policy:
        “The subscribers list is only available to
          the list administrator”. 

        So it is quite hard to know who was on the discussion list and
        thus who participated to the discussion.

    
Since the
        publication is recent (February 14,
        2013), it might be appropriate to ask to the Mozilla community
        to respect the compliance
        

        to the standards. In order to fulfil its needs, the Mozilla
        community
        should:

    
-         
          either define its own
        extension,

    
-         
          or, propose a new
        extension so that it can be published
        in an RFC according to the IETF rules.

    
Any thoughts ?

    
Denis 

        

     
    
    
    
    
    
    
  


--------------050608020508000407000500--


From eabalea@gmail.com  Tue Feb 19 09:08:12 2013
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 3E87C21F8A64 for ; Tue, 19 Feb 2013 09:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level: 
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300,  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 r+OC-GzSCIy9 for ; Tue, 19 Feb 2013 09:08:11 -0800 (PST)
Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4DA21F8A52 for ; Tue, 19 Feb 2013 09:08:11 -0800 (PST)
Received: by mail-vc0-f182.google.com with SMTP id fl17so4444170vcb.13 for ; Tue, 19 Feb 2013 09:08:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uECMospdkywRbMjptomgxUFlAj5ZeYwSw3g6dpPZp5g=; b=iMv0jq3WCiGheE7q0DBmwrn/nOJFXtwHc/BZB8xz7UKFcrHVKEoRhWONTnCzrNmOnZ 9NNohjlmM4K2rQVUaiNxsGlY0ZzFNs4Ffx59TCu9ExrVGvBrGeE6ZvrGdItKWv4BLrBC wzC4ODa8OTT230BMmdgi/8lkoALS5g/j/+YbyvsI1wyswvwHQiPjU4tgf0Gn/IjOq0dK 60W7H5m+drjg1SuVrhtcwACWn6izJOUEBKrmG/GvemXl61pnQbGWgKIi9G8H9W2IRU/M 83AIoHfpNonw+0Uz5CSyTzRQ+n5xlEZbT/oaXE+iCnq3+EYxEqrsqDnnvEFDi2v5gjBN QzQQ==
MIME-Version: 1.0
X-Received: by 10.220.219.208 with SMTP id hv16mr6013418vcb.62.1361293690679;  Tue, 19 Feb 2013 09:08:10 -0800 (PST)
Received: by 10.52.156.49 with HTTP; Tue, 19 Feb 2013 09:08:10 -0800 (PST)
In-Reply-To: <5123AD0B.4050709@bull.net>
References: <5123AD0B.4050709@bull.net>
Date: Tue, 19 Feb 2013 18:08:10 +0100
Message-ID: 
From: Erwann Abalea 
To: Denis Pinkas 
Content-Type: multipart/alternative; boundary=14dae9cfce5ede31e304d616e275
Cc: pkix 
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 19 Feb 2013 17:08:12 -0000

--14dae9cfce5ede31e304d616e275
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonjour,

2013/2/19 Denis Pinkas 
[...]

> Mozilla announces on
> https://lists.mozilla.org/listinfo/dev-security-policy: =E2=80=9C*The sub=
scribers
> list is only available to the list administrator=E2=80=9D. *
>

That's classic.


> So it is quite hard to know who was on the discussion list and thus who
> participated to the discussion.
>

No, the list itself is public. You can use their newsgroup server, or
Google Groups to access it.
The discussion is accessible here
https://groups.google.com/forum/?fromgroups=3D#!topic/mozilla.dev.security.=
policy/Rbc-5j6i-vY


> ****
>
> Since the publication is recent (February 14, 2013), it might be
> appropriate to ask to the Mozilla community to respect the compliance
> to the standards. In order to fulfil its needs, the Mozilla community
> should:****
>
> -          either define its own extension,****
>
> -          or, propose a new extension so that it can be published in an
> RFC according to the IETF rules.****
>
>
I proposed to rely on certificatePolicies extension. That's the purpose of
this extension. Unfortunately, it's often incorrectly used, so that would
need a cleaning step and a definition of standardized policyIds for
specific purposes.

--=20
Erwann.

--14dae9cfce5ede31e304d616e275
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonjour,

2013/2/19 Denis Pinkas <den=
is.pinkas@bull.net>
[...]=C2=A0


Mozilla announces on https://lists.mozilla.org/listinfo/dev-s=
ecurity-policy:
        =E2=80=9CThe subscribers list is onl=
y available to
          the list administrator=E2=80=9D.=C2=A0

That's classic.
=C2=A0



        So it is quite hard to know who was on the discussion list and
        thus who participated to the discussion.

No, the list itself is public. You can use their new=
sgroup server, or Google Groups to access it.
The discussion is a=
ccessible here=C2=A0https://groups.google.c=
om/forum/?fromgroups=3D#!topic/mozilla.dev.security.policy/Rbc-5j6i-vY<=
/div>

=C2=A0


    
Since the
        publication is recent (February 14,
        2013), it might be appropriate to ask to the Mozilla community
        to respect the compliance
        

        to the standards. In order to fulfil its needs, the Mozilla
        community
        should:

    
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
          either define its own
        extension,

    
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
          or, propose a new
        extension so that it can be published
        in an RFC according to the IETF rules.

    

=

I proposed to rely on certificatePolicies extension. That's =
the purpose of this extension. Unfortunately, it's often incorrectly us=
ed, so that would need a cleaning step and a definition of standardized pol=
icyIds for specific purposes.



-- 
Erwann.

--14dae9cfce5ede31e304d616e275--

From david.cooper@nist.gov  Tue Feb 19 10:27:39 2013
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 3D13821F8E64 for ; Tue, 19 Feb 2013 10:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.57
X-Spam-Level: 
X-Spam-Status: No, score=-5.57 tagged_above=-999 required=5 tests=[AWL=-0.429,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 rTkKTAZnMHwf for ; Tue, 19 Feb 2013 10:27:36 -0800 (PST)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id C5AAE21F8E70 for ; Tue, 19 Feb 2013 10:27:32 -0800 (PST)
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.3.123.3; Tue, 19 Feb 2013 13:27:29 -0500
Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.123.3; Tue, 19 Feb 2013 13:27:31 -0500
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 r1JIRV36027646; Tue, 19 Feb 2013 13:27:31 -0500
Message-ID: <5123C412.3090408@nist.gov>
Date: Tue, 19 Feb 2013 13:27:30 -0500
From: "David A. Cooper" 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Denis Pinkas 
References: <5123AD0B.4050709@bull.net>
In-Reply-To: <5123AD0B.4050709@bull.net>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Cc: pkix 
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 19 Feb 2013 18:27:39 -0000


  
    
  
  
    
I raised this issue with Mozilla a few
      months ago (https://bugzilla.mozilla.org/show_bug.cgi?id=725351),
      but didn't get anywhere.

      

      On 02/19/2013 11:49 AM, Denis Pinkas wrote:

    

    

      
      
Mozilla's CA Certificate Policy Version 2.1 is
            available at: http://www.mozilla.org/projects/security/certs/policy/

      
Clause 9 of the Mozilla CA Certificate Inclusion
          Policy (available 

          at http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html)
          states:

      
9.   We
          encourage CAs to technically constrain all subordinate CA
          certificates. For a certificate to be considered 

            technically constrained, the certificate MUST include an
          Extended

            Key Usage (EKU) extension specifying 

          all extended key usages that the subordinate CA is authorized
          to issue certificates for. 

          The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within
          this extension. 

      


            The above link points to : http://tools.ietf.org/html/rfc5280#section-4.2.1.12

          

          

      
  4.2.1.12.  Extended Key Usage

      
 

      
   This extension
            indicates one or more purposes for which the certified

      
   public key may be
            used, in addition to or in place of the basic

      
   purposes indicated in
            the key usage extension.  In
            general, this

      
   extension will appear
            only in end entity certificates.  This

      
   extension is defined
            as follows:

      
 

      
   id-ce-extKeyUsage

            OBJECT IDENTIFIER ::= { id-ce 37 }

      
 

      
   ExtKeyUsageSyntax ::=
            SEQUENCE SIZE (1..MAX) OF KeyPurposeId

      
 

      
   KeyPurposeId ::=
            OBJECT IDENTIFIER

      
 

      
   Key purposes may be
            defined by any organization with a need.  Object

      
   identifiers used to
            identify key purposes MUST be assigned in

      
   accordance with IANA
            or ITU-T Recommendation X.660 [X.660].

      
 

      
   This extension MAY, at
            the option of the certificate issuer, be

      
   either critical or
            non-critical.

      
 

      
   If the extension is
            present, then the certificate MUST only be used

      
   for one of the
            purposes indicated.  If
            multiple purposes are

      
   indicated the
            application need not recognize all purposes indicated,

      
   as long as the
            intended purpose is present. 
            Certificate using

      
   applications MAY
            require that the extended key usage extension be

      
   present and that a
            particular purpose be indicated in order for the

      
   certificate to be
            acceptable to that application.

      
 

      
   If a CA includes
            extended key usages to satisfy such applications,

      
   but does not wish to
            restrict usages of the key, the CA can include

      
   the special
            KeyPurposeId anyExtendedKeyUsage in addition to the

      
   particular key
            purposes required by the applications.  Conforming CAs

      
   SHOULD NOT mark this
            extension as critical if the anyExtendedKeyUsage

      
   KeyPurposeId is
            present.  Applications
            that require the presence of a

      
   particular purpose MAY
            reject certificates that include the

      
   anyExtendedKeyUsage
            OID but not the particular OID expected for the

      
   application.

      
 

      
   If a certificate
            contains both a key usage extension and an extended

      
   key usage extension,
            then both extensions MUST be processed

      
   independently and the
            certificate MUST only be used for a purpose

      
   consistent with both
            extensions.  If there
            is no purpose consistent

      
   with both extensions,
            then the certificate MUST NOT be used for any

      
   purpose.

      
 

      
IMO, the semantics of the EKU extension, as
          defined in RFC 5280 and in X.509, does not allow using 

          that extension in the way which is described in this document.
          

      
 

      
I have informed Mozilla (certificates@mozilla.org) of the issue and the answer was a pointer to a FAQ, 
which includes the following statement (https://wiki.mozilla.org/CA:CertificatePolicyV2.1).

      
Frequently Asked Questions 

      
    
        
  1. RFC 5280
            reads "In general, this extension will appear only in end
            entity certificates". 
    
            Is it non-standard to have EKU in intermediate certificates,
            and will client software break when receiving such a
            certificate chain? 
    2. 
        
      
          
    • Inclusion of EKU in CA certificates is generally
              allowed. NSS and CryptoAPI both treat the EKU extension in
              intermediate certificates 
      
              as a constraint on the permitted EKU OIDs in end-entity
              certificates. Browsers and certificate client software
              have been using EKU 
      
              in intermediate certificates, and it has been common for
              enterprise subordinate CAs in Windows environments to use
              EKU in their 
      
              intermediate certificates to constrain certificate
              issuance. Therefore, it is unlikely that using EKU in
              intermediate certificates would 
      
              break other client software. 
      • 
          
    • The use of the EKU extension in intermediate
              certificates was discussed at length in the mozilla.dev.security.policy


                forum. 
      
              We considered other options, such as standardizing a set
              of Policy OIDs or un-deprecating NetscapeCertType. The
              discussion included 
      
              the concern that one interpretation of RFC 5280
              is that this use of EKU is non-standard, but it
                was decided that the RFCs are not clear, 
      
                and perhaps conflicting, in regards to EKUs in CA
                certificates      . In the discussion it was pointed
              out that other major browsers and client 
      
              software already support this use of EKU but do not
              recognize NetscapeCertType; and we also recognized the
              difficulties involved in 
      
              standardizing a set of Policy OIDs. The conclusion of the
              discussion was that EKU is the best tool for technically
              constraining the types 
      
              of certificates that an intermediate certificate may sign.
              
      • 
        
    
      

      
 

      
The
          OID for EKU is the following: {joint-iso-itu-t(2)
          ds(5) certificateExtension(29) extKeyUsage(37)}

      
http://www.oid-info.com/get/2.5.29.37 indicates:

      
“This

          field indicates one or more purposes for which the certified
          public key may be used, in addition to or in place of the
          basic purposes indicated 

          in the key usage extension field.

          

          More information can be found in Recommendation

              ITU-T X.509 (March 2000) and in ISO/IEC
              9594-8 (2001): "Directory: Public-key and attribute 

          certificate frameworks".

      

      
      
The
          text from the last available recommendation ITU-X.509 is as
          follows:

      
“  8.2.2.4 Extended key
          usage extension

      
This
          field indicates one or more purposes for which the certified
          public key may be used, in addition to or in place of the
          basic purposes 

          indicated in the key usage extension field. This field is
          defined as follows:

      
extKeyUsage
            EXTENSION ::= {

      
SYNTAX
            SEQUENCE SIZE (1..MAX) OF KeyPurposeId

      
IDENTIFIED
            BY id-ce-extKeyUsage }

      
KeyPurposeId
            ::= OBJECT IDENTIFIER

      
A CA
          may assert any-extended-key-usage by using the
          anyExtendedKeyUsage identifier. This enables a CA to issue a
          certificate 

          that contains OIDs for extended key usages that may be
          required by certificate-using applications, without
          restricting the certificate 

          to only those key usages. If extended key usage would restrict
          key usage, then the inclusion of this OID removes that
          restriction.

      
anyExtendedKeyUsage

            OBJECT IDENTIFIER ::= { 2 5 29 37 0 }[S9]

      
Key
          purposes may be defined by any organization with a need.
          Object identifiers used to identify key purposes shall be
          assigned 

          in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.

      
This
          extension may, at the option of the certificate issuer, be
          either critical or non-critical.

      
If
          the extension is flagged critical, then the certificate shall
          be used only for one of the purposes indicated.

      
If
          the extension is flagged non-critical, then it indicates the
          intended purpose or purposes of the key, and may be used in
          finding 

          the correct key/certificate of an entity that has multiple
          keys/certificates. If this extension is present, and the
          certificate-using system 

          recognizes and processes the extendedKeyUsage extension type,
          then the certificate-using system shall ensure that the
          certificate 

          shall be used only for one of the purposes indicated. (Using
          applications may nevertheless require that a particular
          purpose be indicated 

          in order for the certificate to be acceptable to that
          application.)

      
If a
          certificate contains both a critical key usage field and a
          critical extended key usage field, then both fields shall be
          processed i

          ndependently and the certificate shall only be used for a
          purpose consistent with both fields. If there is no purpose
          consistent with both fields, 

          then the certificate shall not be used for any purpose”.

      
 

      
Mozilla
          announces on https://lists.mozilla.org/listinfo/dev-security-policy:
          “The subscribers list is only available
            to the list administrator”. 

          So it is quite hard to know who was on the discussion list and
          thus who participated to the discussion.

      
Since the publication is recent (February 14,
          2013), it might be appropriate to ask to the Mozilla community
          to respect the compliance 

          to the standards. In order to fulfil its needs, the Mozilla
          community should:

      
-          either define its own extension,

      
-          or, propose a new extension so that it can be
          published in an RFC according to the IETF rules.

      
Any thoughts ?

      
Denis 

          

       
      
      
      
      
      
       

    

  


From piyush@ditenity.com  Tue Feb 19 11:06:46 2013
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 41DC921F8E7A for ; Tue, 19 Feb 2013 11:06:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level: 
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=-2.306,  BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, DYN_RDNS_SHORT_HELO_HTML=0.499,  FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_LT4=0.442, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.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 iMSOS646w8I9 for ; Tue, 19 Feb 2013 11:06:45 -0800 (PST)
Received: from mail-yh0-x22f.google.com (yh-in-x022f.1e100.net [IPv6:2607:f8b0:4002:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6C321F8E79 for ; Tue, 19 Feb 2013 11:06:45 -0800 (PST)
Received: by mail-yh0-f47.google.com with SMTP id w68so1257657yhw.34 for ; Tue, 19 Feb 2013 11:06:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=P2M9gav1M8T08tC0HN1h9IqpD3b8lZPCY1KYAozfkO8=; b=ch3zuh06mCh7+vcm51b7IxAh2X3UvCoqoFj6XRwDP9w4IWNXiMVAtjUmc/7M41v/6e mjOB46+FXksfV3DWyOsjXAmxHHXg95U+opiCCAdqAoJx5HQcKdSEvVJbrBz7JQaN9/ir PZuB57AidymFo04okgme5xIjt7p59UDGYBoGpzq1pcztn+6aK2jekxeOUU+H7jOfCJkA H2acDG4SlXIBtqvoH5cmfOI7aLxOOWTFUxpAAyxq0hgpUA0oKS19arFPhv84+XrrFD8B /9d7RHygORHFKaami2J2jNoEfWxqtWkWW+u1rNcxPf59ngUtr5I6QEqR7gnANXH05coO 69QQ==
X-Received: by 10.236.125.201 with SMTP id z49mr30943540yhh.93.1361300804512;  Tue, 19 Feb 2013 11:06:44 -0800 (PST)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id x16sm126339467yhj.6.2013.02.19.11.06.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Feb 2013 11:06:43 -0800 (PST)
From: "Piyush Jain" 
To: "'Denis Pinkas'" , "'pkix'" 
References: <5123AD0B.4050709@bull.net>
In-Reply-To: <5123AD0B.4050709@bull.net>
Date: Tue, 19 Feb 2013 11:06:36 -0800
Message-ID: <046b01ce0ed4$3e736a90$bb5a3fb0$@ditenity.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_046C_01CE0E91.30516310"
X-Mailer: Microsoft Outlook 14.0
thread-index: AQE/GVrKDYpSvoZGL3wrGRKim2gAYJmfYr4Q
Content-Language: en-us
X-Gm-Message-State: ALoCoQnfrGbhv1UoWGW+5hG2oLjObsWr4fGSh0pLBhsvhsltie/I8SZvKjuOH10dUklGcw9+lAgJ
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 19 Feb 2013 19:06:46 -0000

This is a multipart message in MIME format.

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

Since the publication is recent (February 14, 2013), it might be appropriate
to ask to the Mozilla community to respect the compliance 
to the standards. In order to fulfil its needs, the Mozilla community
should:

-          either define its own extension,

-          or, propose a new extension so that it can be published in an RFC
according to the IETF rules.

Any thoughts ?

Denis 



[Piyush] What mozilla is doing is non-standard and mozilla community should
realize that they are doing a disservice to their customers by recommending
this. Their enterprise customers may not understand that EKU constraints
deployed in this way will not be followed by other clients.

Unfortunately this WG has already set precedence to twist the standards to
accommodate non-compliant, insecure implementations as long as the install
base is huge. One cannot fault Mozilla to first make sure that these changes
are adopted before it proposes any standards change. 

Having said that, there may be a genuine requirement to constraint sub CAs
on the EKUs they can put in a certificate that they issue. Given that there
is no documented use case of putting EKU in CA certificates, what is the
harm in standardizing what Mozilla is doing? 


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


Since the publication is =
recent (February 14, 2013), it might be appropriate to ask to the =
Mozilla community to respect the compliance 
to the standards. In =
order to fulfil its needs, the Mozilla community =
should:
-        =
;  either define its own =
extension,
-        =
;  or, propose a new extension =
so that it can be published in an RFC according to the IETF =
rules.
Any thoughts =
?
Denis 

[Piyush] What mozilla is doing is non-standard and mozilla community =
should realize that they are doing a disservice to their customers by =
recommending this. Their enterprise customers may not understand that =
EKU constraints deployed in this way will not be followed by other =
clients.
Unfortunately this WG has already set precedence to twist the =
standards to accommodate non-compliant, insecure implementations as long =
as the install base is huge. One cannot fault Mozilla to first make sure =
that these changes are adopted before it proposes any standards change. =

Having said that, there may be a genuine requirement to constraint =
sub CAs on the EKUs they can put in a certificate that they issue. Given =
that there is no documented use case of putting EKU in CA certificates, =
what is the harm in standardizing what Mozilla is doing? =


------=_NextPart_000_046C_01CE0E91.30516310--


From stefan@aaa-sec.com  Tue Feb 19 11:18:15 2013
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 F016B1F0D14 for ; Tue, 19 Feb 2013 11:18:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.852
X-Spam-Level: 
X-Spam-Status: No, score=-100.852 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 GrtFz1S0KBmQ for ; Tue, 19 Feb 2013 11:18:09 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id D897C21F8C1E for ; Tue, 19 Feb 2013 11:18:05 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 31BB3412E84 for ; Tue, 19 Feb 2013 20:18:03 +0100 (CET)
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 HckQrJ2jD92O for ; Tue, 19 Feb 2013 20:17:57 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 54675412E69 for ; Tue, 19 Feb 2013 20:17:57 +0100 (CET)
Received: (qmail 17503 invoked from network); 19 Feb 2013 19:17:56 -0000
Received: from 81-236-19-140-no39.tbcn.telia.com (HELO [192.168.1.88]) (stefan@fiddler.nu@[81.236.19.140]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Feb 2013 19:17:56 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Tue, 19 Feb 2013 20:17:55 +0100
From: Stefan Santesson 
To: Denis Pinkas , pkix 
Message-ID: 
Thread-Topic: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
In-Reply-To: <5123AD0B.4050709@bull.net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3444149878_5304060"
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 19 Feb 2013 19:18:15 -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_3444149878_5304060
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Denis,

This is for me a since long well known fact.
Back in 2004 I managed Microsofts revision of X.509 path processing where
most standards deviations were removed or corrected. This one was
deliberately preserved. As it was a too well established method to contrain
cert usages.
Variants of this was (and probably still is) used to for example only allow
code signing EKU if that cert is supported by a path and a root that allows
code signing.
In absence of any other suitable mechanism this one was preserved.
Earlier MS had tried to invent an EKU like extension (Application Policy),
that had path processing properties, but due to lack of support of this
extension. Application Policy was abandoned.

This is one of these area where theory and practice deviate, and probably
will continue to do so for considerable time.
I raised the issue when we revised 3280 to 5280, but concluded that the
standards community was as unlikely to adopt MS implementation of EKU as it
was unlikely that MS would stop doing it.

/Stefan


From:  Denis Pinkas 
Date:  Tuesday, February 19, 2013 5:49 PM
To:  pkix 
Subject:  [pkix] A non-compliant use of the EKU extension in Mozilla's CA
Certificate Policy Version 2.1.

>    =20
>  =20
> Mozilla's CA Certificate Policy Version 2.1 is available at:
> http://www.mozilla.org/projects/security/certs/policy/
> =20
>=20
> Clause 9 of the Mozilla CA Certificate Inclusion Policy (available
>  at=20
> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.htm=
l)
> states:
> =20
> 9.   We encourage CAs to technically constrain all subordinate CA
> certificates. For a certificate to be considered
>  technically constrained, the certificate MUST include an Extended Key Us=
age
> (EKU)   extension
> specifying=20
>  all extended key usages that the subordinate CA is authorized to issue
> certificates for.
>  The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extensi=
on.
> =20
>=20
>  The above link points to :
> http://tools.ietf.org/html/rfc5280#section-4.2.1.12
> =20
> =20
> =20
>   4.2.1.12=20
>  .
> Extended Key Usage
> =20
> =20
> =20
>    This extension indicates one or more purposes for which the certified
> =20
>    public key may be used, in addition to or in place of the basic
> =20
>    purposes indicated in the key usage extension.  In general, this
> =20
>    extension will appear only in end entity certificates.  This
> =20
>    extension is defined as follows:
> =20
> =20
> =20
>    id-ce-extKeyUsage OBJECT IDENTIFIER ::=3D { id-ce 37 }
> =20
> =20
> =20
>    ExtKeyUsageSyntax ::=3D SEQUENCE SIZE (1..MAX) OF KeyPurposeId
> =20
> =20
> =20
>    KeyPurposeId ::=3D OBJECT IDENTIFIER
> =20
> =20
> =20
>    Key purposes may be defined by any organization with a need.  Object
> =20
>    identifiers used to identify key purposes MUST be assigned in
> =20
>    accordance with IANA or ITU-T Recommendation X.660 [X.660].
> =20
> =20
> =20
>    This extension MAY, at the option of the certificate issuer, be
> =20
>    either critical or non-critical.
> =20
> =20
> =20
>    If the extension is present, then the certificate MUST only be used
> =20
>    for one of the purposes indicated.  If multiple purposes are
> =20
>    indicated the application need not recognize all purposes indicated,
> =20
>    as long as the intended purpose is present.  Certificate using
> =20
>    applications MAY require that the extended key usage extension be
> =20
>    present and that a particular purpose be indicated in order for the
> =20
>    certificate to be acceptable to that application.
> =20
> =20
> =20
>    If a CA includes extended key usages to satisfy such applications,
> =20
>    but does not wish to restrict usages of the key, the CA can include
> =20
>    the special KeyPurposeId anyExtendedKeyUsage in addition to the
> =20
>    particular key purposes required by the applications.  Conforming CAs
> =20
>    SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage
> =20
>    KeyPurposeId is present.  Applications that require the presence of a
> =20
>    particular purpose MAY reject certificates that include the
> =20
>    anyExtendedKeyUsage OID but not the particular OID expected for the
> =20
>    application.
> =20
> =20
> =20
>    If a certificate contains both a key usage extension and an extended
> =20
>    key usage extension, then both extensions MUST be processed
> =20
>    independently and the certificate MUST only be used for a purpose
> =20
>    consistent with both extensions.  If there is no purpose consistent
> =20
>    with both extensions, then the certificate MUST NOT be used for any
> =20
>    purpose.
> =20
> =20
> =20
> IMO, the semantics of the EKU extension, as defined in RFC 5280 and in X.=
509,
> does not allow using
>  that extension in the way which is described in this document.
> =20
> =20
> =20
> I have informed Mozilla (certificates@mozilla.org) of the issue and the a=
nswer
> was a pointer to a FAQ,
> which includes the following statement
> (https://wiki.mozilla.org/CA:CertificatePolicyV2.1
>  ).
> =20
> Frequently Asked Questions
> =20
> 1. RFC 5280   reads "In general, this
> extension will appear only in end entity certificates".
> 2.  Is it non-standard to have EKU in intermediate certificates, and will
> client software break when receiving such a certificate chain?
>> * Inclusion of EKU in CA certificates is generally allowed. NSS and Cryp=
toAPI
>> both treat the EKU extension in intermediate certificates
>> *  as a constraint on the permitted EKU OIDs in end-entity certificates.
>> Browsers and certificate client software have been using EKU
>> *  in intermediate certificates, and it has been common for enterprise
>> subordinate CAs in Windows environments to use EKU in their
>> *  intermediate certificates to constrain certificate issuance. Therefor=
e, it
>> is unlikely that using EKU in intermediate certificates would
>> *  break other client software.
>> * The use of the EKU extension in intermediate certificates was discusse=
d at
>> length in the mozilla.dev.security.policy  forum.
>> > iAxxo> =20
>> *  We considered other options, such as standardizing a set of Policy OI=
Ds or
>> un-deprecating NetscapeCertType. The discussion included
>> *  the concern that one interpretation of RFC 5280
>>   is that this use of EKU is
>> non-standard, but it was decided that the RFCs are not clear,
>> *  and perhaps conflicting, in regards to EKUs in CA certificates. In th=
e
>> discussion it was pointed out that other major browsers and client
>> *  software already support this use of EKU but do not recognize
>> NetscapeCertType; and we also recognized the difficulties involved in
>> *  standardizing a set of Policy OIDs. The conclusion of the discussion =
was
>> that EKU is the best tool for technically constraining the types
>> *  of certificates that an intermediate certificate may sign.
> =20
> =20
> =20
> The OID for EKU is the following: {joint-iso-itu-t(2) ds(5)
> certificateExtension(29) extKeyUsage(37)}
> =20
> http://www.oid-info.com/get/2.5.29.37 
> indicates:
> =20
> =B3This field indicates one or more purposes for which the certified public=
 key
> may be used, in addition to or in place of the basic purposes indicated
>  in the key usage extension field.
> =20
>  More information can be found in Recommendation ITU-T X.509 (March 2000)
>  9-200003-s>  and in ISO/IEC 9594-8 (2001)
>  : "Directory:
> Public-key and attribute
>  certificate frameworks".
> =20
>  =20
> The text from the last available recommendation ITU-X.509 is as follows:
> =20
> =B3  8.2.2.4 Extended key usage extension
> =20
> This field indicates one or more purposes for which the certified public =
key
> may be used, in addition to or in place of the basic purposes
>  indicated in the key usage extension field. This field is defined as fol=
lows:
> =20
> extKeyUsage EXTENSION ::=3D {
> =20
> SYNTAX SEQUENCE SIZE (1..MAX) OF KeyPurposeId
> =20
> IDENTIFIED BY id-ce-extKeyUsage }
> =20
> KeyPurposeId ::=3D OBJECT IDENTIFIER
> =20
> A CA may assert any-extended-key-usage by using the anyExtendedKeyUsage
> identifier. This enables a CA to issue a certificate
>  that contains OIDs for extended key usages that may be required by
> certificate-using applications, without restricting the certificate
>  to only those key usages. If extended key usage would restrict key usage=
,
> then the inclusion of this OID removes that restriction.
> =20
> anyExtendedKeyUsage OBJECT IDENTIFIER ::=3D { 2 5 29 37 0 }[S9]
> =20
> Key purposes may be defined by any organization with a need. Object
> identifiers used to identify key purposes shall be assigned
>  in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.
> =20
> This extension may, at the option of the certificate issuer, be either
> critical or non-critical.
> =20
> If the extension is flagged critical, then the certificate shall be used =
only
> for one of the purposes indicated.
> =20
> If the extension is flagged non-critical, then it indicates the intended
> purpose or purposes of the key, and may be used in finding
>  the correct key/certificate of an entity that has multiple keys/certific=
ates.
> If this extension is present, and the certificate-using system
>  recognizes and processes the extendedKeyUsage extension type, then the
> certificate-using system shall ensure that the certificate
>  shall be used only for one of the purposes indicated. (Using application=
s may
> nevertheless require that a particular purpose be indicated
>  in order for the certificate to be acceptable to that application.)
> =20
> If a certificate contains both a critical key usage field and a critical
> extended key usage field, then both fields shall be processed i
>  ndependently and the certificate shall only be used for a purpose consis=
tent
> with both fields. If there is no purpose consistent with both fields,
>  then the certificate shall not be used for any purpose=B2.
> =20
> =20
> =20
> Mozilla announces on https://lists.mozilla.org/listinfo/dev-security-poli=
cy:
> =B3The subscribers list is only available to the list administrator=B2.
>  So it is quite hard to know who was on the discussion list and thus who
> participated to the discussion.
> =20
> Since the publication is recent (February 14, 2013), it might be appropri=
ate
> to ask to the Mozilla community to respect the compliance
>  to the standards. In order to fulfil its needs, the Mozilla community sh=
ould:
> =20
> -          either define its own extension,
> =20
> -          or, propose a new extension so that it can be published in an =
RFC
> according to the IETF rules.
> =20
> Any thoughts ?
> =20
> Denis=20
> =20
>         =20
> _______________________________________________ pkix mailing list
> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix



--B_3444149878_5304060
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


Denis,

<=
div>This is for me a since long well known fact.
Back in 2004 I ma=
naged Microsofts revision of X.509 path processing where most standards devi=
ations were removed or corrected. This one was deliberately preserved. As it=
 was a too well established method to contrain cert usages.
Varian=
ts of this was (and probably still is) used to for example only allow code s=
igning EKU if that cert is supported by a path and a root that allows code s=
igning.
In absence of any other suitable mechanism this one was pr=
eserved.
Earlier MS had tried to invent an EKU like extension (App=
lication Policy), that had path processing properties, but due to lack of su=
pport of this extension. Application Policy was abandoned.

This is one of these area where theory and practice deviate, and pro=
bably will continue to do so for considerable time.
I raised the i=
ssue when we revised 3280 to 5280, but concluded that the standards communit=
y was as unlikely to adopt MS implementation of EKU as it was unlikely that =
MS would stop doing it.

/Stefan


From:  Denis Pinkas <<=
a href=3D"mailto:denis.pinkas@bull.net">denis.pinkas@bull.net>
Date:  Tuesday, February 19, 2013 5:49 PMTo:  pkix <pkix@ietf.org>
Subject:  [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certif=
icate Policy Version 2.1.


  

    
  
  

    
    
Mozilla's CA Certificate Policy Version 2=
.1 is
          available at: http://www.mozilla.org/projects/security/certs/policy/<=
/span>

    
Clause 9 of the
        Mozilla CA Certificate
        Inclusion Policy (available 

        at http://www.m=
ozilla.org/projects/security/certs/policy/InclusionPolicy.html)
        states:

    
9.   We encourage CAs to technically constrain =
all
        subordinate CA
        certificates. For a certificate to be considered 

          technically constrained,
        the certificate MUST include an Extended
          Key Usage
          (EKU) extension specifying 

        all extended key usages that the subordinate CA
        is authorized to issue certificates for. 

        The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this
        extension. 

    


          The
          above link points to : http://tools.ietf.org/html/rfc5280#section-=
4.2.1.12

        

        

    
  4.2.1.12.  Exten=
ded
          Key Usage<=
/span>

    
 

    
   This extension indicates
          one or more
          purposes for which the certified

    
   public key may be used,
          in addition to or in
          place of the basic

    
   purposes indicated in
          the key usage
          extension.  In general=
,
          this

    
   extension will appear
          only in end entity
          certificates.  This

    
   extension is defined as
          follows:

    
 

    
   id-ce-extKeyUsage
          OBJECT IDENTIFIER ::=3D { id-ce 37 }

    
 

    
   ExtKeyUsageSyntax ::=3D SEQUENCE
          SIZE (1..MAX) OF
          KeyPurposeId

    
 

    
   KeyPurposeId ::=3D OBJECT
          IDENTIFIER

    
 

    
   Key purposes may be
          defined by any
          organization with a need.  Object

    
  
          identifiers used to identify key purposes MUST be
          assigned in

    
   accordance with IANA or
          ITU-T Recommendation
          X.660 [X.660].

    
 

    
   This extension MAY, at
          the option of the
          certificate issuer, be

    
   either critical or
          non-critical.

    
 

    
   If the extension is
          present, then the
          certificate MUST only be used

    
   for one of the purposes
          indicated.  If multipl=
e
          purposes are

    
   indicated the
          application need not recognize
          all purposes indicated,

    
   as long as the intended
          purpose is
          present.  Certificate
          using

    
   applications MAY require
          that the extended
          key usage extension be

    
   present and that a
          particular purpose be
          indicated in order for the

    
   certificate to be
          acceptable to that
          application.

    
 

    
   If a CA includes
          extended key usages to
          satisfy such applications,

    
   but does not wish to
          restrict usages of the
          key, the CA can include

    
   the special KeyPurposeId
          anyExtendedKeyUsage
          in addition to the

    
   particular key purposes
          required by the
          applications.  Conform=
ing
          CAs

    
   SHOULD NOT mark this
          extension as critical
          if the anyExtendedKeyUsage

    
   KeyPurposeId is present.  Applications that require
          the presence of a

    
   particular purpose MAY
          reject certificates
          that include the

    
   anyExtendedKeyUsage OID
          but not the
          particular OID expected for the

    
   application.

    
 

    
   If a certificate
          contains both a key usage
          extension and an extended

    
   key usage extension,
          then both extensions
          MUST be processed

    
   independently and the
          certificate MUST only
          be used for a purpose

    
   consistent with both
          extensions.  If there
          is no purpose consistent

    
   with both extensions,
          then the certificate
          MUST NOT be used for any

    
   purpose.

    
 =


    
IMO, the semantics
        of the EKU extension, as
        defined in RFC 5280 and in X.509, does not allow using 

        that extension in the
        way which is described in this document. 

    
 

    
I have informed Mozilla (certificates@mozilla.org) of the issue and=
 the answer was a pointer to a FAQ, 
which includes the following statement (https://wiki.mozilla.org/CA:CertificatePolicyV2.1).

    
Frequently=

          Asked Questions 

    
    
      
  1. RFC 5280 reads
          "In general, this extension will appear only in end entity
          certificates". 
    
          Is it non-standard to have EKU in intermediate certificates,
          and will client software break when receiving such a
          certificate chain? 
    2. 
      
      
        
    • Inclusion of EKU in CA
            certificates is generally allowed. NSS and CryptoAPI both
            treat the EKU extension in intermediate certificates 
      
            as a constraint on the permitted EKU OIDs in end-entity
            certificates. Browsers and certificate client software have
            been using EKU 
      
            in intermediate certificates, and it has been common for
            enterprise subordinate CAs in Windows environments to use
            EKU in their 
      
            intermediate certificates to constrain certificate issuance.
            Therefore, it is unlikely that using EKU in intermediate
            certificates would 
      
            break other client software. 
      • 
        
    • The use of the EKU extension
            in intermediate certificates was discussed at length in the
            mozilla.dev.security.policy

              forum. 
      
            We considered other options, such as standardizing a set of
            Policy OIDs or un-deprecating NetscapeCertType. The
            discussion included 
      
            the concern that one interpretation of RFC 5280 is
            that this use of EKU is non-standard, but it was
              decided that the RFCs are not clear, 
      
              and perhaps conflicting, in regards to EKUs in CA
              certificates      . In the discussion it was pointed out
            that other major browsers and client 
      
            software already support this use of EKU but do not
            recognize NetscapeCertType; and we also recognized the
            difficulties involved in 
      
            standardizing a set of Policy OIDs. The conclusion of the
            discussion was that EKU is the best tool for technically
            constraining the types 
      
            of certificates that an intermediate certificate may sign. 
      • 
      
    
    

    
 
    
The OID for EKU is the
        following: {joint-iso-itu-t(2)
ds(5)
        certificateExtension(29) extKeyUsage(37)}

    
http://www.oid-info.com/get/2.5.29.37
        indicates:

    
“Th=
is
        field indicates one or more
        purposes for which the certified public key may be used, in
        addition to or in
        place of the basic purposes indicated 

        in the key usage extension field.

        

        More information can be found in Recommendation
            ITU-T X.509 (March
            2000) and in ISO/IEC 9594-8=

            (2001):
        "Directory: Public-key and attribute 

        certificate frameworks".

    

    
    
The
        text from the last available
        recommendation ITU-X.509 is as follows:

    
“ 
        8.2.2.4 Extended key usage extension

    
This
        field indicates one or more purposes
        for which the certified public key may be used, in addition to
        or in place of
        the basic purposes 

        indicated in the key usage extension field. This field is
        defined as follows:

    
extKeyUsage EXTENSION
          ::=3D {

    
SYNTAX SEQUENCE SIZE
          (1..MAX) OF KeyPurposeId

    
IDENTIFIED BY
          id-ce-extKeyUsage }

    
KeyPurposeId ::=3D OBJECT
          IDENTIFIER
    
A CA
        may assert
        any-extended-key-usage by using the anyExtendedKeyUsage
        identifier. This
        enables a CA to issue a certificate 

        that contains OIDs for extended key usages
        that may be required by certificate-using applications, without
        restricting the
        certificate 

        to only those key usages. If extended key usage would restrict
        key
        usage, then the inclusion of this OID removes that restriction.

    
anyExtendedKeyUsage
          OBJECT IDENTIFIER ::=3D { 2 5 29 37
          0 }[S9]

    
Key
        purposes may be defined by any
        organization with a need. Object identifiers used to identify
        key purposes
        shall be assigned 

        in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.

    
This
        extension may, at the option
        of the certificate issuer, be either critical or non-critical.=


    
If the
        extension is flagged
        critical, then the certificate shall be used only for one of the
        purposes
        indicated.

    
If the
        extension is flagged
        non-critical, then it indicates the intended purpose or purposes
        of the key,
        and may be used in finding 

        the correct key/certificate of an entity that has
        multiple keys/certificates. If this extension is present, and
        the
        certificate-using system 

        recognizes and processes the extendedKeyUsage
        extension type, then the certificate-using system shall ensure
        that the
        certificate 

        shall be used only for one of the purposes indicated. (Using
        applications may nevertheless require that a particular purpose
        be indicated 

        in
        order for the certificate to be acceptable to that application.)

    
If a
        certificate contains both a
        critical key usage field and a critical extended key usage
        field, then both
        fields shall be processed i

        ndependently and the certificate shall only be used
        for a purpose consistent with both fields. If there is no
        purpose consistent with
        both fields, 

        then the certificate shall not be used for any purpose”.=


    
 
    
Mozilla announces on https://lists.moz=
illa.org/listinfo/dev-security-policy:
        “The subscribers list is only available to
          the list administrator”. 

        So it is quite hard to know who was on the discussion list and
        thus who participated to the discussion.

    
Since the
        publication is recent (February 14,
        2013), it might be appropriate to ask to the Mozilla community
        to respect the compliance
        

        to the standards. In order to fulfil its needs, the Mozilla
        community
        should:

    
-       &=
nbsp; 
          either define its own
        extension,

    
-       &=
nbsp; 
          or, propose a new
        extension so that it can be published
        in an RFC according to the IETF rules.

    
Any thoughts ?

    
Denis 

        

     
    
    
    
    
    
    
  

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/m=
ailman/listinfo/pkix



--B_3444149878_5304060--



From kent@bbn.com  Tue Feb 19 12:29:59 2013
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 0D8DA21F8B6D for ; Tue, 19 Feb 2013 12:29:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ebA-3g8PEZZW for ; Tue, 19 Feb 2013 12:29:58 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 776B421F8B69 for ; Tue, 19 Feb 2013 12:29:58 -0800 (PST)
Received: from dhcp89-089-230.bbn.com ([128.89.89.230]:52139) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U7tp6-0006gR-TE; Tue, 19 Feb 2013 15:29:56 -0500
Message-ID: <5123E0C7.5020506@bbn.com>
Date: Tue, 19 Feb 2013 15:29:59 -0500
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Denis Pinkas , pkix 
References: <5123AD0B.4050709@bull.net>
In-Reply-To: <5123AD0B.4050709@bull.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 19 Feb 2013 20:29:59 -0000

Denis,

I agree with your analysis of the situation, as seconded by David Cooper.

I think it unfortunate that Mozilla is advising folks to use EKU in a 
fashion that is not supported
by X.509 or 5280. (Specifically, a compliant RP should not reject a 
subordinate cert based on an EKU value
encountered in a CA cert higher in a cert path.)

While I appreciate the desire to have this sort of transitive scoping 
expressed via an EKU,
that extension, unlike some others in X.509/5280, does not offer this 
feature.  It would be
preferable to define a nee extension, rather that misinterpret an 
existing one.

Sorry, Stefan, but just because MS earlier did this doesn't make it 
right :-).

Steve


From pgut001@cs.auckland.ac.nz  Tue Feb 19 16:26:48 2013
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 5DA4A21F86D3 for ; Tue, 19 Feb 2013 16:26:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.405
X-Spam-Level: 
X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194,  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 TN1lKyf2kLcn for ; Tue, 19 Feb 2013 16:26:41 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 871B521F85F5 for ; Tue, 19 Feb 2013 16:26:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1361320002; x=1392856002; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=14HtrKbN9S9EYDGQ8hN6CMi6DQEoH5jRnnmQUjnPBeA=; b=UbhwcX1Ariyp5z/7IehZKyMSVoUIRKoh2FFkImtyu/BuPOyl5Hz1XtCF G9Z50W51UvVZA/lP6fGA1se5+TC0CGB/1mJxofh0sfWiovKtJxqArnnNI IbFg4pTnn4yuHYPCKEQkw0n29AT1dcaVCHB4ZfpGzwrTt9PlhZK4k22kF 0=;
X-IronPort-AV: E=Sophos;i="4.84,698,1355050800"; d="scan'208";a="171262057"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 20 Feb 2013 13:26:40 +1300
Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.108]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 13:26:39 +1300
From: Peter Gutmann 
To: IETF PKIX 
Thread-Topic: [pkix] purpose of LDAP in PKI
Thread-Index: Ac4PAPMWr+0uKZsTQZ6spXmF37JQAw==
Date: Wed, 20 Feb 2013 00:26:39 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C733340E7AA@uxcn10-2.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] purpose of LDAP in PKI
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, 20 Feb 2013 00:26:48 -0000

"Kemp, David P."  writes:=0A=
=0A=
>It would be trivial to specify certificate search, retrieval, update=0A=
>transactions over HTTP, but the set of such transactions has not been=0A=
>standardized.=0A=
=0A=
RFC 4387.=0A=
=0A=
Peter.=0A=

From pgut001@cs.auckland.ac.nz  Tue Feb 19 16:41:40 2013
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 8A40821F87C3 for ; Tue, 19 Feb 2013 16:41:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.412
X-Spam-Level: 
X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187,  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 gpslp9xV-cNx for ; Tue, 19 Feb 2013 16:41:39 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5E521F87AB for ; Tue, 19 Feb 2013 16:41:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1361320899; x=1392856899; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BmyLeeoQozn2Jy5KItBVbRhfKUqrDINOozGdu0K9ldo=; b=FBAAx62J6f9m9f/YRWl05kggGhIze/4XMpU+dGt6XhA0kLvhp9jv/ea3 8uO5PgLBjbtrO1t/WZ7B3SqzOTzCtr+hek/4+bGr+WlNOBXRVUqQbYmWv DgIhdc8pYXCpf+298d+7vhwx3cWLmxXMrARUKtVOd+k6qZp0QPoMKMLpI c=;
X-IronPort-AV: E=Sophos;i="4.84,698,1355050800"; d="scan'208";a="171264482"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 20 Feb 2013 13:41:38 +1300
Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe1.UoA.auckland.ac.nz (130.216.4.112) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 20 Feb 2013 13:41:38 +1300
Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.108]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 13:41:38 +1300
From: Peter Gutmann 
To: IETF PKIX 
Thread-Topic: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
Thread-Index: Ac4PAwrGDFDziHtuR1+/bLq7NHvjsA==
Date: Wed, 20 Feb 2013 00:41:38 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C733340E7BB@uxcn10-2.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 00:41:40 -0000

Stephen Kent  writes:=0A=
=0A=
>I think it unfortunate that Mozilla is advising folks to use EKU in a fash=
ion=0A=
>that is not supported by X.509 or 5280. (Specifically, a compliant RP shou=
ld=0A=
>not reject a subordinate cert based on an EKU value encountered in a CA ce=
rt=0A=
>higher in a cert path.)=0A=
=0A=
The other way of looking at it is that it's unfortunate that PKIX refuses t=
o=0A=
standardise a widely-used and -adopted practice.  As Stefan pointed out, th=
is=0A=
is just another case of reality vs. PKIX, reality will keep being what it i=
s=0A=
and PKIX will keep going down its own path, unconstrained by reality.=0A=
=0A=
Peter.=0A=

From dev+ietf@seantek.com  Tue Feb 19 20:53:57 2013
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 ACAE821F87A3 for ; Tue, 19 Feb 2013 20:53:57 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj3jL+1ZMr-e for ; Tue, 19 Feb 2013 20:53:56 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id BEB4E21F87AB for ; Tue, 19 Feb 2013 20:53:56 -0800 (PST)
Received: from [192.168.123.119] (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 30538509B8 for ; Tue, 19 Feb 2013 23:53:56 -0500 (EST)
Message-ID: <512456E3.8060401@seantek.com>
Date: Tue, 19 Feb 2013 20:53:55 -0800
From: Sean Leonard 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: pkix@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C733340E7AA@uxcn10-2.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C733340E7AA@uxcn10-2.UoA.auckland.ac.nz>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050901070209020002070009"
Subject: Re: [pkix] purpose of LDAP in PKI
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, 20 Feb 2013 04:53:57 -0000

This is a cryptographically signed message in MIME format.

--------------ms050901070209020002070009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 2/19/2013 4:26 PM, Peter Gutmann wrote:
> "Kemp, David P."  writes:
>
>> It would be trivial to specify certificate search, retrieval, update
>> transactions over HTTP, but the set of such transactions has not been
>> standardized.
> RFC 4387.
>
+1.

-Sean


--------------ms050901070209020002070009
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKSzCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIFKTCCBBGgAwIBAgIQZ6sVlrTEYjwLaBPoxUwEaTANBgkqhkiG9w0B
AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP
TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjEx
MjkwMDAwMDBaFw0xMzExMjkyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNl
YW50ZWsuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz
5zgTny0JRBE1mJZszV2s6EurahKPvku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/
+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cUvZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9r
BB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/MwNAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyV
ZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/syYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfc
k36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQABo4IB5DCCAeAwHwYDVR0jBBgwFoAU
ehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBpm5d7y8PBT6NqnIVbfNK8hbpPGMA4G
A1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEE
AbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEw
KzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAw
TjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAC
hkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j
b20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2VhbnRlay5jb20wDQYJKoZIhvcNAQEFBQADggEB
AAY3GfgX0pLsz6qEOOG191EgYXSCpKW70wSFgSe+7AenZT88d/m8w0YtfOFVD7+94dNULDnH
4P6sD70hday7/ke4uYfgURxygemKN26KV3T7wBw8WbZSTmYJphzSoqUK5ISsQNwLaKf4yTmp
Ae9IR1AjZXP3oAZvsRvpZDtiaULQ+HfFTypLDsnrA7sTtoVtirJdImGBTHsVtZ+GEQlhuuJ6
G1cInzNxIbxgnLdn4pFF82FP60SsZxaW2VRqDK7CbHJX4LUH+oJ6kp9qxF5I/RIAhRHd3lMe
Xmq6vZPbnMUNhJyUC6TbYipe11+VDFPGiHZE/+y6RMSuRnepJzE4PLAxggQZMIIEFQIBATCB
qDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE
BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9E
TyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQZ6sVlrTEYjwL
aBPoxUwEaTAJBgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xMzAyMjAwNDUzNTVaMCMGCSqGSIb3DQEJBDEWBBT0GUkBGzNjPz7BWBER
W/58hASfvTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI
KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG
SIb3DQMCAgEoMIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQI
ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E
TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFu
ZCBTZWN1cmUgRW1haWwgQ0ECEGerFZa0xGI8C2gT6MVMBGkwgbsGCyqGSIb3DQEJEAILMYGr
oIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD
VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N
T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBnqxWWtMRi
PAtoE+jFTARpMA0GCSqGSIb3DQEBAQUABIIBAJ94nMtv55A4mN6pzEKp7uofHlkHdxFNI3wt
7PrZRYRVi+KIZb80XoXXBA+iulks+CaCObvlQafn2PL5GqMPixsCUl29Q4X3OOZRSBhQNyu+
v4oFoStWIYT1+EsZCOTJjGkdMQNihYHvSWrSEbYGx205KHNTTuWE1BHFBNoOkngjQdp612+T
U95yRjO7NnqUD9n+p/RH0zCrLIiMGSlJES/e6UVQNqjZDXvRM5sUrU69IIhnhzMxR9k2iBM7
C3ds30lxjnkI5elQXmk48zjceNcxldxrDMOhEzWgBKiV0tO1lyFNvMqhDJ1jOmHweaiy1NtF
2hadHhjUuT/13Jcih8UAAAAAAAA=
--------------ms050901070209020002070009--

From hallam@gmail.com  Wed Feb 20 05:42:49 2013
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 A909321F87BA for ; Wed, 20 Feb 2013 05:42:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.814
X-Spam-Level: 
X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[AWL=-2.216, 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 tUY1K5QsBnVe for ; Wed, 20 Feb 2013 05:42:48 -0800 (PST)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9BD21F8754 for ; Wed, 20 Feb 2013 05:42:48 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hm6so6216362wib.2 for ; Wed, 20 Feb 2013 05:42:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Vn/uMeaPa8JclTcI8X3HecI9P3TlrrhmnCOZRCSHfPY=; b=JwNUmd3Z/BDUu47npSVrjA0Wb0JlYZv85qvBy4FzwvIY7g4nIK9hsHIw0aYsvYmt7h yA1kS9lh/46jxGzn+xwHZbp9E1mVQn5O9GO2IuDhvSc8ZA0sfQXyxUDpfVTxXkfojKxl +cGzKyZbuBR/a2NUnRH80FMiWpkfCzAHr0aAvdP+SgA629b6lrSD6wLFBimRNBp0wC0j x7YPXihwK2dz713Z34n8wQkuo4QYA/pSyiJ56vkcuArJiziEF0YN2HfSu7XtDbuxqpol CEpTrxRnx8GyhfAtJyE0VJqV5QYTAEcDNTj3RoaMsrq/a5ieQDoPREpDNjaRrgV+Ovvh sLfA==
MIME-Version: 1.0
X-Received: by 10.194.86.38 with SMTP id m6mr33992130wjz.13.1361367767558; Wed, 20 Feb 2013 05:42:47 -0800 (PST)
Received: by 10.194.11.71 with HTTP; Wed, 20 Feb 2013 05:42:47 -0800 (PST)
In-Reply-To: <2555EA5F-E28F-404A-A9F9-074ACBAEE78E@vpnc.org>
References: <9A043F3CF02CD34C8E74AC1594475C733340DA1B@uxcn10-2.UoA.auckland.ac.nz> <003b01ce0df2$717801e0$546805a0$@eu> <20130218171244.AAF9821F8AD8@ietfa.amsl.com> <5B1D7E570380A64989D4C069F7D14BC868A058D4@clavin.missi.ncsc.mil> <2555EA5F-E28F-404A-A9F9-074ACBAEE78E@vpnc.org>
Date: Wed, 20 Feb 2013 08:42:47 -0500
Message-ID: 
From: Phillip Hallam-Baker 
To: Paul Hoffman 
Content-Type: multipart/alternative; boundary=089e0102f9f831a9fe04d62822d4
Cc: "pkix@ietf.org" 
Subject: Re: [pkix] purpose of LDAP in PKI
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, 20 Feb 2013 13:42:49 -0000

--089e0102f9f831a9fe04d62822d4
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 19, 2013 at 10:16 AM, Paul Hoffman wrote:

> On Feb 19, 2013, at 6:25 AM, "Kemp, David P." 
> wrote:
>
> > That misses the point.  LDAP defines an application protocol that
> supports transactions with known semantics, allowing M2M communications
> based on published standards rather than bespoke specifications.   HTTP
> does not define application semantics -- HTML, SOAP, REST, etc perform that
> function in the HTTP space.
> >
> > It would be trivial to specify certificate search, retrieval, update
> transactions over HTTP, but the set of such transactions has not been
> standardized.
>
> *cough* RFC 2585 *cough* (To be honest, I wouldn't have remembered it
> unless I had be co-author.)
>
> >  Every Internet-connected device has a DNS resolver that allows machines
> to manage and exchange resource data without human intervention.
>  Certificates could be managed as DNS resources (in theory - there is
> resistance to that idea in practice) using only TCP/UDP and the published
> DNS specs.  LDAP can do that with just the published TCP and LDAP specs.
> >
> > If a set of DNS-over-HTTP or directory-over-HTTP transactions were
> defined, HTTP could support M2M management and distribution of DNS and
> certificate resources.  But those transactions aren't standardized, so HTTP
> alone cannot be considered an "application protocol" with respect to DNS
> resources, SQL databases, or directories.
>
> What is not specified is a single URL patter to find a particular
> certificate.
>

What was never finished was the one mechanism that a client can apply to
translate an SMTP email recipient address to the corresponding S/MIME
configuration (including cert).

Sharon Boyen and myself tried to do this a while back but got no uptake.
Possibly because of the lack of a decent DNS API on the platforms.


I have found LDAP to be nothing more than a waste of time and an
opportunity for enterprise IT department empire building. People can spend
months or years designing a directory deployment and the result works no
better than a HTTP repository does.

As for HTTP not being an application protocol or incomplete. That is
nonsense. Neither LDAP nor HTTP can be applied to the problem without
additional configuration choices being made. In the case of HTTP the
choices do not matter in the slightest except that they not be completely
crazy and that someone actually makes a choice so that there is one way to
do it. In the case of LDAP the DIT arc has implications that are far from
simple and has to be configured on a site by site basis.





-- 
Website: http://hallambaker.com/

--089e0102f9f831a9fe04d62822d4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Tue, Feb 19, 2013 at 10:16 AM, Paul H=
offman <paul.hoffman@vpnc.org> wrote:


On Feb 19, 2013, at 6:25 AM, "Kemp, David P." &=
lt;dpkemp@missi.ncsc.mil> w=
rote:



> That misses the point. =A0LDAP defines an application protocol that su=
pports transactions with known semantics, allowing M2M communications based=
 on published standards rather than bespoke specifications. =A0 HTTP does n=
ot define application semantics -- HTML, SOAP, REST, etc perform that funct=
ion in the HTTP space.


>

> It would be trivial to specify certificate search, retrieval, update t=
ransactions over HTTP, but the set of such transactions has not been standa=
rdized.




*cough* RFC 2585 *cough* (To be honest, I wouldn't have remembere=
d it unless I had be co-author.)




> =A0Every Internet-connected device has a DNS resolver that allows mach=
ines to manage and exchange resource data without human intervention. =A0Ce=
rtificates could be managed as DNS resources (in theory - there is resistan=
ce to that idea in practice) using only TCP/UDP and the published DNS specs=
. =A0LDAP can do that with just the published TCP and LDAP specs.


>

> If a set of DNS-over-HTTP or directory-over-HTTP transactions were def=
ined, HTTP could support M2M management and distribution of DNS and certifi=
cate resources. =A0But those transactions aren't standardized, so HTTP =
alone cannot be considered an "application protocol" with respect=
 to DNS resources, SQL databases, or directories.





What is not specified is a single URL patter to find a particular cer=
tificate.

What was never finished was t=
he one mechanism that a client can apply to translate an SMTP email recipie=
nt address to the corresponding S/MIME configuration (including cert).


Sharon Boyen and myself tried to do this a while back b=
ut got no uptake. Possibly because of the lack of a decent DNS API on the p=
latforms.


I have found LDAP to be n=
othing more than a waste of time and an opportunity for enterprise IT depar=
tment empire building. People can spend months or years designing a directo=
ry deployment and the result works no better than a HTTP repository does.


As for HTTP not being an application protocol or incomp=
lete. That is nonsense. Neither LDAP nor HTTP can be applied to the problem=
 without additional configuration choices being made. In the case of HTTP t=
he choices do not matter in the slightest except that they not be completel=
y crazy and that someone actually makes a choice so that there is one way t=
o do it. In the case of LDAP the DIT arc has implications that are far from=
 simple and has to be configured on a site by site basis.







=

-- 
Website: http://hallambake=
r.com/


--089e0102f9f831a9fe04d62822d4--

From denis.pinkas@bull.net  Wed Feb 20 06:50:23 2013
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 E19A721F87FB for ; Wed, 20 Feb 2013 06:50:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 u3EOdrbrDo+8 for ; Wed, 20 Feb 2013 06:50:22 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4711A21F8802 for ; Wed, 20 Feb 2013 06:50:22 -0800 (PST)
Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 60B431D2B6 for ; Wed, 20 Feb 2013 15:50:21 +0100 (CET)
Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2013022015502031-42830 ; Wed, 20 Feb 2013 15:50:20 +0100 
Message-ID: <5124E2AB.5020400@bull.net>
Date: Wed, 20 Feb 2013 15:50:19 +0100
From: Denis Pinkas 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: pkix@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C733340E7BB@uxcn10-2.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C733340E7BB@uxcn10-2.UoA.auckland.ac.nz>
X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 20/02/2013 15:50:20, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 20/02/2013 15:50:21, Serialize complete at 20/02/2013 15:50:21
X-TNEFEvaluated: 1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 14:50:24 -0000

Peter,

I believe that you are missing a point in the standardization process:
once an OID has been defined, its semantics CANNOT be changed.

You will also notice that the OID for EKU has NOT been assigned by the 
IETF, but by ISO/ ITU-T.
So PKIX is unable to make any change in the semantics, and it is the 
same for ISO/ITU-T even
with the best will.

I do not think it would be reasonable to change the semantics of what an 
OID is.

Thus the reality is not the one you describe, but the fact that large 
companies are ignoring standards and
it is time to let them understand that the software they provide is not 
compliant with the standards.

Denis

> Stephen Kent  writes:
>
>> I think it unfortunate that Mozilla is advising folks to use EKU in a fashion
>> that is not supported by X.509 or 5280. (Specifically, a compliant RP should
>> not reject a subordinate cert based on an EKU value encountered in a CA cert
>> higher in a cert path.)
> The other way of looking at it is that it's unfortunate that PKIX refuses to
> standardise a widely-used and -adopted practice.  As Stefan pointed out, this
> is just another case of reality vs. PKIX, reality will keep being what it is
> and PKIX will keep going down its own path, unconstrained by reality.
>
> Peter.
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix



From kent@bbn.com  Wed Feb 20 06:56:08 2013
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 2A02121F8726 for ; Wed, 20 Feb 2013 06:56:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 QzKmlveZ8lJ0 for ; Wed, 20 Feb 2013 06:56:07 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id AA80C21F8759 for ; Wed, 20 Feb 2013 06:56:07 -0800 (PST)
Received: from dhcp89-089-230.bbn.com ([128.89.89.230]:52381) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U8B5Z-000Am0-B5; Wed, 20 Feb 2013 09:56:05 -0500
Message-ID: <5124E404.2080500@bbn.com>
Date: Wed, 20 Feb 2013 09:56:04 -0500
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Peter Gutmann , pkix 
References: <9A043F3CF02CD34C8E74AC1594475C733340E7BB@uxcn10-2.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C733340E7BB@uxcn10-2.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 14:56:08 -0000

If all widely-used -adopted practices were good, we would adopt more of 
them.

That is clearly not the case. And, often, those who choose to adopt a 
practice
that contradicts the standards do so before approaching PKIX. In such 
cases, adopting
what has been done encourages the practice of avoiding the IETF process 
in favor
of a "big vendor has decided to do X, so let's reward them with an RFC."

That's a bad idea in any WG context.

Steve


On 2/19/13 7:41 PM, Peter Gutmann wrote:
> Stephen Kent  writes:
>
>> I think it unfortunate that Mozilla is advising folks to use EKU in a fashion
>> that is not supported by X.509 or 5280. (Specifically, a compliant RP should
>> not reject a subordinate cert based on an EKU value encountered in a CA cert
>> higher in a cert path.)
> The other way of looking at it is that it's unfortunate that PKIX refuses to
> standardise a widely-used and -adopted practice.  As Stefan pointed out, this
> is just another case of reality vs. PKIX, reality will keep being what it is
> and PKIX will keep going down its own path, unconstrained by reality.
>
> Peter.
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>


From piyush@ditenity.com  Wed Feb 20 07:40:49 2013
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 DDCDF21F87C6 for ; Wed, 20 Feb 2013 07:40:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.316
X-Spam-Level: 
X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[AWL=-1.912, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_LT4=0.442, RDNS_DYNAMIC=0.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 cnrEWxK9WvJI for ; Wed, 20 Feb 2013 07:40:49 -0800 (PST)
Received: from mail-gg0-x235.google.com (mail-gg0-x235.google.com [IPv6:2607:f8b0:4002:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5C30421F87BA for ; Wed, 20 Feb 2013 07:40:49 -0800 (PST)
Received: by mail-gg0-f181.google.com with SMTP id e5so1014526ggh.26 for ; Wed, 20 Feb 2013 07:40:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=DXoYqZA0EkuK3gMkvMqcaewbIr5EsxcmiZEKtNkMH/A=; b=lfa+TTNj/ldwGDyvulEyZ12VGN3sOKenCVhfW4yBTBdsk4mqkH6iigb0stl6qsPLtY /9cNCqCuQ9kuQvrhatwTm6CNFLIHrXvJFDl46Gmb2WU8ay0FrQJFTJB1Ss3YMi7rtnTQ K1yFfl0EgeVfy0IKNXTUceD3rsbnv+6G7vLjZyac/+sB8zCwMAGz4/USEYmxNmVckZmZ nFAV/HA6Z6zuhmT1zkhesAiXDy+YQm9hpPjh/MZIc/uzQcBYnMX2MY7kY59Ekb1IeOF2 QYpOPtw/d0Bv1+QiNb5wd3D8E8fcpu8UIESmejrSwKIAxPnZuMHn92ChvZnY4k7qq4TT IF9Q==
X-Received: by 10.236.117.104 with SMTP id i68mr36825958yhh.125.1361374848557;  Wed, 20 Feb 2013 07:40:48 -0800 (PST)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id f3sm66886663ani.3.2013.02.20.07.40.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 Feb 2013 07:40:47 -0800 (PST)
From: "Piyush Jain" 
To: "'Stephen Kent'" , "'Peter Gutmann'" , "'pkix'" 
References: <9A043F3CF02CD34C8E74AC1594475C733340E7BB@uxcn10-2.UoA.auckland.ac.nz> <5124E404.2080500@bbn.com>
In-Reply-To: <5124E404.2080500@bbn.com>
Date: Wed, 20 Feb 2013 07:40:46 -0800
Message-ID: <008f01ce0f80$a7c06f00$f7414d00$@ditenity.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFU+PKJgpk+Of64p5F/KTAfGYydCwMKzW3EmVyy3DA=
Content-Language: en-us
X-Gm-Message-State: ALoCoQnzR+OglMiVdruIK5DDZLq/CdewkkprxNLco5Gjn87zYh1/DsLwfPbmgXDd4isBlYXgHvvc
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 15:40:50 -0000

+1 for the response below.

Unfortunately the precedence has been set by changing standards to
accommodate implementations that incorrectly treat unknown certificates as
good in violation of 5280.
Don't underestimate the lobbying muscles of the browser forum. This time
they have two of the biggest corporations behind them :).


> -----Original Message-----
> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
> Stephen Kent
> Sent: Wednesday, February 20, 2013 6:56 AM
> To: Peter Gutmann; pkix
> Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's
CA
> Certificate Policy Version 2.1.
> 
> If all widely-used -adopted practices were good, we would adopt more of
> them.
> 
> That is clearly not the case. And, often, those who choose to adopt a
practice
> that contradicts the standards do so before approaching PKIX. In such
cases,
> adopting what has been done encourages the practice of avoiding the IETF
> process in favor of a "big vendor has decided to do X, so let's reward
them
> with an RFC."
> 
> That's a bad idea in any WG context.
> 
> Steve
> 
> 
> On 2/19/13 7:41 PM, Peter Gutmann wrote:
> > Stephen Kent  writes:
> >
> >> I think it unfortunate that Mozilla is advising folks to use EKU in a
> >> fashion that is not supported by X.509 or 5280. (Specifically, a
> >> compliant RP should not reject a subordinate cert based on an EKU
> >> value encountered in a CA cert higher in a cert path.)
> > The other way of looking at it is that it's unfortunate that PKIX
> > refuses to standardise a widely-used and -adopted practice.  As Stefan
> > pointed out, this is just another case of reality vs. PKIX, reality
> > will keep being what it is and PKIX will keep going down its own path,
> unconstrained by reality.
> >
> > Peter.
> > _______________________________________________
> > 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 stefan@aaa-sec.com  Wed Feb 20 07:46:38 2013
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 73B1221F8806 for ; Wed, 20 Feb 2013 07:46:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.661
X-Spam-Level: 
X-Spam-Status: No, score=-101.661 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 IVPg0SSqE7WY for ; Wed, 20 Feb 2013 07:46:37 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6913F21F87E4 for ; Wed, 20 Feb 2013 07:46:36 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 4EB4741F12D for ; Wed, 20 Feb 2013 16:46:32 +0100 (CET)
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 fZVf93MrdJkz for ; Wed, 20 Feb 2013 16:46:29 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 20DE241F088 for ; Wed, 20 Feb 2013 16:46:26 +0100 (CET)
Received: (qmail 7772 invoked from network); 20 Feb 2013 15:46:25 -0000
Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.208]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 20 Feb 2013 15:46:25 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Wed, 20 Feb 2013 16:46:20 +0100
From: Stefan Santesson 
To: Stephen Kent , Denis Pinkas , pkix 
Message-ID: 
Thread-Topic: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
In-Reply-To: <5123E0C7.5020506@bbn.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 15:46:38 -0000

Steve,

I don't make any statement in the context of right and wrong.

I'm merely exploring the facts of the case.

Another fact of the case is that implementers priority often put customer
demands and what works first.
This is done as far as possible by following standards, but if necessary,
by stretching them and if necessary by breaking them.

What can make those organisations change attitude is, I'm afraid, not a
yard stick held up by a standards body.

The present case is as far as I can see a complete deadlock.
Nor ITU/ISO nor PKIX can change the meaning of EKU, neither can
implementers do what they feel they need to do without breaking/stretching
the standard.

/Stefan


On 2/19/13 9:29 PM, "Stephen Kent"  wrote:

>Denis,
>
>I agree with your analysis of the situation, as seconded by David Cooper.
>
>I think it unfortunate that Mozilla is advising folks to use EKU in a
>fashion that is not supported
>by X.509 or 5280. (Specifically, a compliant RP should not reject a
>subordinate cert based on an EKU value
>encountered in a CA cert higher in a cert path.)
>
>While I appreciate the desire to have this sort of transitive scoping
>expressed via an EKU,
>that extension, unlike some others in X.509/5280, does not offer this
>feature.  It would be
>preferable to define a nee extension, rather that misinterpret an
>existing one.
>
>Sorry, Stefan, but just because MS earlier did this doesn't make it
>right :-).
>
>Steve
>
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix



From piyush@ditenity.com  Wed Feb 20 08:13:27 2013
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 82F0721F8639 for ; Wed, 20 Feb 2013 08:13:27 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+aILKH3tE2m for ; Wed, 20 Feb 2013 08:13:26 -0800 (PST)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0A321F8633 for ; Wed, 20 Feb 2013 08:13:26 -0800 (PST)
Received: by mail-qa0-f46.google.com with SMTP id o13so2489783qaj.19 for ; Wed, 20 Feb 2013 08:13:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=NSYi3L5nUNPE9BQ5rQ07SjmEpJoFSVPpDc6qm8ed4qE=; b=X2Q9+0rmm2nmcqwK1cxTPkTPm6WgrBQit4hXW2xeD+2qaYfy4WEyd2DjqClvWsn46d s9JjaEBXFnNsmiq/Qlbto+VZEOx0qtOTQ97ROFoJj3oCZEKdxG4b2MhW8Bv2Ut/hpVsn QXe/xi1+od98eOrJys+SpE0HKwUTOxx473w01O4luJ/Muu1JrUSJIVyw+hAdwsgGtjho BJWsYtmJVqn8yKKGiC1FgxyA14Y9cPJmtdPZToZJOslVnEwdWKyTzRcyRxndbIsuK8Uh TU6KsRitHZkrZCUJ59OyaBBYWLZwIcWI0JNm0gLumaDWXA5WFqad1xCCh/0F1T+XN8gS YVuQ==
MIME-Version: 1.0
X-Received: by 10.224.186.81 with SMTP id cr17mr9515634qab.99.1361376806068; Wed, 20 Feb 2013 08:13:26 -0800 (PST)
Received: by 10.49.14.34 with HTTP; Wed, 20 Feb 2013 08:13:25 -0800 (PST)
X-Originating-IP: [166.137.185.37]
Received: by 10.49.14.34 with HTTP; Wed, 20 Feb 2013 08:13:25 -0800 (PST)
In-Reply-To: 
References: <5123E0C7.5020506@bbn.com> 
Date: Wed, 20 Feb 2013 08:13:25 -0800
Message-ID: 
From: Piyush Jain 
To: Stefan Santesson 
Content-Type: multipart/alternative; boundary=485b397dcddbee60b404d62a3c19
X-Gm-Message-State: ALoCoQmam89xZm8hyO3q4n7YsIyccKHLDKguavFsoaUAn/eV79nZ14fM3cedYEMBzrctKg8DdQGr
Cc: pkix 
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 16:13:27 -0000

--485b397dcddbee60b404d62a3c19
Content-Type: text/plain; charset=ISO-8859-1

really?

implementers can choose to define another eku like extension with a
different OID. it does not break the standards and serves their need.
Their attitude will change only when their customers start complaining that
their products are cannot inter operate with others because they don't
follow the standards.
On Feb 20, 2013 7:46 AM, "Stefan Santesson"  wrote:

> Steve,
>
> I don't make any statement in the context of right and wrong.
>
> I'm merely exploring the facts of the case.
>
> Another fact of the case is that implementers priority often put customer
> demands and what works first.
> This is done as far as possible by following standards, but if necessary,
> by stretching them and if necessary by breaking them.
>
> What can make those organisations change attitude is, I'm afraid, not a
> yard stick held up by a standards body.
>
> The present case is as far as I can see a complete deadlock.
> Nor ITU/ISO nor PKIX can change the meaning of EKU, neither can
> implementers do what they feel they need to do without breaking/stretching
> the standard.
>
> /Stefan
>
>
> On 2/19/13 9:29 PM, "Stephen Kent"  wrote:
>
> >Denis,
> >
> >I agree with your analysis of the situation, as seconded by David Cooper.
> >
> >I think it unfortunate that Mozilla is advising folks to use EKU in a
> >fashion that is not supported
> >by X.509 or 5280. (Specifically, a compliant RP should not reject a
> >subordinate cert based on an EKU value
> >encountered in a CA cert higher in a cert path.)
> >
> >While I appreciate the desire to have this sort of transitive scoping
> >expressed via an EKU,
> >that extension, unlike some others in X.509/5280, does not offer this
> >feature.  It would be
> >preferable to define a nee extension, rather that misinterpret an
> >existing one.
> >
> >Sorry, Stefan, but just because MS earlier did this doesn't make it
> >right :-).
> >
> >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
>

--485b397dcddbee60b404d62a3c19
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


really?


 implementers can choose to define another eku like extension with a dif=
ferent OID. it does not break the standards and serves their need.

Their attitude will change only when their customers start complaining that=
 their products are cannot inter operate with others because they don't=
 follow the standards.


On Feb 20, 2013 7:46 AM, "Stefan Santesson&=
quot; <stefan@aaa-sec.com> =
wrote:

Steve,



I don't make any statement in the context of right and wrong.



I'm merely exploring the facts of the case.



Another fact of the case is that implementers priority often put customer
demands and what works first.

This is done as far as possible by following standards, but if necessary,
by stretching them and if necessary by breaking them.



What can make those organisations change attitude is, I'm afraid, not a=


yard stick held up by a standards body.



The present case is as far as I can see a complete deadlock.

Nor ITU/ISO nor PKIX can change the meaning of EKU, neither can

implementers do what they feel they need to do without breaking/stretching<=
br>
the standard.



/Stefan





On 2/19/13 9:29 PM, "Stephen Kent" <kent@bbn.com> wrote:



>Denis,

>

>I agree with your analysis of the situation, as seconded by David Coope=
r.

>

>I think it unfortunate that Mozilla is advising folks to use EKU in a
>fashion that is not supported

>by X.509 or 5280. (Specifically, a compliant RP should not reject a

>subordinate cert based on an EKU value

>encountered in a CA cert higher in a cert path.)

>

>While I appreciate the desire to have this sort of transitive scoping
>expressed via an EKU,

>that extension, unlike some others in X.509/5280, does not offer this
>feature. =A0It would be

>preferable to define a nee extension, rather that misinterpret an

>existing one.

>

>Sorry, Stefan, but just because MS earlier did this doesn't make it=


>right :-).

>

>Steve

>

>_______________________________________________

>pkix mailing list

>pkix@ietf.org

>https://www.ietf.org/mailman/listinfo/pkix





_______________________________________________

pkix mailing list

pkix@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/pkix




--485b397dcddbee60b404d62a3c19--

From SChokhani@cygnacom.com  Wed Feb 20 08:17:30 2013
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 7A30821F863F for ; Wed, 20 Feb 2013 08:17:30 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCNGx9d+y6Rn for ; Wed, 20 Feb 2013 08:17:28 -0800 (PST)
Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id B94BA21F8881 for ; Wed, 20 Feb 2013 08:17:27 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,702,1355115600"; d="scan'208,217";a="7895162"
Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 20 Feb 2013 11:17:25 -0500
Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 20 Feb 2013 11:15:14 -0500
From: Santosh Chokhani 
To: Piyush Jain , Stefan Santesson 
Date: Wed, 20 Feb 2013 11:15:12 -0500
Thread-Topic: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
Thread-Index: Ac4PhTq4xcbtrLZgSrK4Yz2GzlLbFAAACdvw
Message-ID: 
References: <5123E0C7.5020506@bbn.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_B83745DA469B7847811819C5005244AFF3DC903Fscygexch7cygnac_"
MIME-Version: 1.0
Cc: pkix 
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 16:17:30 -0000

--_000_B83745DA469B7847811819C5005244AFF3DC903Fscygexch7cygnac_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Actually MSFT has (or had it).  It  is (was) "application policies.

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Piy=
ush Jain
Sent: Wednesday, February 20, 2013 11:13 AM
To: Stefan Santesson
Cc: pkix
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's C=
A Certificate Policy Version 2.1.


really?

implementers can choose to define another eku like extension with a differe=
nt OID. it does not break the standards and serves their need.
Their attitude will change only when their customers start complaining that=
 their products are cannot inter operate with others because they don't fol=
low the standards.
On Feb 20, 2013 7:46 AM, "Stefan Santesson" > wrote:
Steve,

I don't make any statement in the context of right and wrong.

I'm merely exploring the facts of the case.

Another fact of the case is that implementers priority often put customer
demands and what works first.
This is done as far as possible by following standards, but if necessary,
by stretching them and if necessary by breaking them.

What can make those organisations change attitude is, I'm afraid, not a
yard stick held up by a standards body.

The present case is as far as I can see a complete deadlock.
Nor ITU/ISO nor PKIX can change the meaning of EKU, neither can
implementers do what they feel they need to do without breaking/stretching
the standard.

/Stefan


On 2/19/13 9:29 PM, "Stephen Kent" > wrot=
e:

>Denis,
>
>I agree with your analysis of the situation, as seconded by David Cooper.
>
>I think it unfortunate that Mozilla is advising folks to use EKU in a
>fashion that is not supported
>by X.509 or 5280. (Specifically, a compliant RP should not reject a
>subordinate cert based on an EKU value
>encountered in a CA cert higher in a cert path.)
>
>While I appreciate the desire to have this sort of transitive scoping
>expressed via an EKU,
>that extension, unlike some others in X.509/5280, does not offer this
>feature.  It would be
>preferable to define a nee extension, rather that misinterpret an
>existing one.
>
>Sorry, Stefan, but just because MS earlier did this doesn't make it
>right :-).
>
>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

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


Actually =
MSFT has (or had it).  It  is (was) “application policies.<=
o:p>
 
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.=
org] On Behalf Of Piyush Jain
Sent: Wednesday, February 20=
, 2013 11:13 AM
To: Stefan Santesson
Cc: pkix
Sub=
ject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's =
CA Certificate Policy Version 2.1.
 
really?
implementers can choose =
to define another eku like extension with a different OID. it does not brea=
k the standards and serves their need.
Their attitude will change only w=
hen their customers start complaining that their products are cannot inter =
operate with others because they don't follow the standards.
=

On Feb 20, 2013 7:46 AM, "Stefan Santesson&q=
uot; <stefan@aaa-sec.com> w=
rote:
Steve,

I don't make any sta=
tement in the context of right and wrong.

I'm merely exploring the f=
acts of the case.

Another fact of the case is that implementers prio=
rity often put customer
demands and what works first.
This is done as=
 far as possible by following standards, but if necessary,
by stretching=
 them and if necessary by breaking them.

What can make those organis=
ations change attitude is, I'm afraid, not a
yard stick held up by a sta=
ndards body.

The present case is as far as I can see a complete dead=
lock.
Nor ITU/ISO nor PKIX can change the meaning of EKU, neither canimplementers do what they feel they need to do without breaking/stretching=

the standard.

/Stefan


On 2/19/13 9:29 PM, "Steph=
en Kent" <kent@bbn.com> wrot=
e:

>Denis,
>
>I agree with your analysis of the situa=
tion, as seconded by David Cooper.
>
>I think it unfortunate th=
at Mozilla is advising folks to use EKU in a
>fashion that is not sup=
ported
>by X.509 or 5280. (Specifically, a compliant RP should not re=
ject a
>subordinate cert based on an EKU value
>encountered in =
a CA cert higher in a cert path.)
>
>While I appreciate the des=
ire to have this sort of transitive scoping
>expressed via an EKU,>that extension, unlike some others in X.509/5280, does not offer this<=
br>>feature.  It would be
>preferable to define a nee extensi=
on, rather that misinterpret an
>existing one.
>
>Sorry, =
Stefan, but just because MS earlier did this doesn't make it
>right :=
-).
>
>Steve
>
>___________________________________=
____________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing li=
st
pkix@ietf.org
https://www.ietf.=
org/mailman/listinfo/pkix
=

--_000_B83745DA469B7847811819C5005244AFF3DC903Fscygexch7cygnac_--

From eabalea@gmail.com  Wed Feb 20 08:27:00 2013
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 A7EAB21F8915 for ; Wed, 20 Feb 2013 08:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.448
X-Spam-Level: 
X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150,  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 alY-Q98PU377 for ; Wed, 20 Feb 2013 08:26:47 -0800 (PST)
Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5883121F86A1 for ; Wed, 20 Feb 2013 08:26:44 -0800 (PST)
Received: by mail-ve0-f181.google.com with SMTP id d10so7108834vea.12 for ; Wed, 20 Feb 2013 08:26:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wXnTEYm6//InU7QIPVrK7jusqNDPN1QWzzRHX0GZ27E=; b=bC7uNdQpnspWRfd79l7w9zrf+yHf00qewL5R8BwYTnzD7s59zoZZLtmo34Wu+UUNp+ EcjK1NDbn8iBHxW/9mxebHNH7jqAN91dsdl/Wn1DGMEHibQ7h2JAkAqJ28FfC3/ReN7o bzulx+363X43T/kaBcfbCLxMWp3juSvXu3EfrklZjoXi77wdo/zyeGkxHlt1J3Hfie0G aZKHvcP/Tyqm4BfcBKl+HdskPiKvJHog8nFWNd8p0582SW2Lr7gwy9hLRRgIlcT1sQFD 8nGPE7d/ywbLnyq7MIIkDF1jROPhx4VQYnwfFSkO6kDuifLTN9Qe+2eJ4/fy8Bb6cFsK 9xXg==
MIME-Version: 1.0
X-Received: by 10.220.219.208 with SMTP id hv16mr11015149vcb.62.1361377597610;  Wed, 20 Feb 2013 08:26:37 -0800 (PST)
Received: by 10.52.156.49 with HTTP; Wed, 20 Feb 2013 08:26:37 -0800 (PST)
In-Reply-To: 
References: <5123E0C7.5020506@bbn.com>  
Date: Wed, 20 Feb 2013 17:26:37 +0100
Message-ID: 
From: Erwann Abalea 
To: Piyush Jain 
Content-Type: multipart/alternative; boundary=14dae9cfce5e1c5c5d04d62a6cd0
Cc: Stefan Santesson , pkix 
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 16:27:00 -0000

--14dae9cfce5e1c5c5d04d62a6cd0
Content-Type: text/plain; charset=UTF-8

2013/2/20 Piyush Jain 

> really?
>
> implementers can choose to define another eku like extension with a
> different OID. it does not break the standards and serves their need.
> Their attitude will change only when their customers start complaining
> that their products are cannot inter operate with others because they don't
> follow the standards.
>
They can define their own extension, like MS ApplicationPolicy, or
NetscapeCertType.
They can also rely on CertificatePolicies (which they do for EV
certificates, and are starting to do for DV/OV).

-- 
Erwann.

--14dae9cfce5e1c5c5d04d62a6cd0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


2013/2/20 Piyush Jain <=
piyush@ditenity.co=
m>


really?


 implementers can choose to define another eku like extension with a dif=
ferent OID. it does not break the standards and serves their need.

Their attitude will change only when their customers start complaining that=
 their products are cannot inter operate with others because they don't=
 follow the standards.
They can define their own=
 extension, like MS ApplicationPolicy, or NetscapeCertType.


They can also rely on CertificatePolicies (which they do for EV certif=
icates, and are starting to do for DV/OV).

-- 
Erwan=
n.

--14dae9cfce5e1c5c5d04d62a6cd0--

From lists@drh-consultancy.co.uk  Wed Feb 20 08:54:41 2013
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 C48A821F8718 for ; Wed, 20 Feb 2013 08:54:41 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF09azCSwX-7 for ; Wed, 20 Feb 2013 08:54:40 -0800 (PST)
Received: from claranet-outbound-smtp06.uk.clara.net (claranet-outbound-smtp06.uk.clara.net [195.8.89.39]) by ietfa.amsl.com (Postfix) with ESMTP id DC47021F8722 for ; Wed, 20 Feb 2013 08:54:39 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:1035 helo=[192.168.7.8]) by relay06.mail.eu.clara.net (relay.clara.net [213.253.3.46]:10465) with esmtpa (authdaemon_plain:drh) id 1U8CwF-0001op-LN for pkix@ietf.org (return-path ); Wed, 20 Feb 2013 16:54:35 +0000
Message-ID: <5124FFCD.8010405@drh-consultancy.co.uk>
Date: Wed, 20 Feb 2013 16:54:37 +0000
From: Dr Stephen Henson 
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: pkix@ietf.org
References: <5123E0C7.5020506@bbn.com>   
In-Reply-To: 
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 16:54:41 -0000

On 20/02/2013 16:26, Erwann Abalea wrote:
> 
> They can define their own extension, like MS ApplicationPolicy, or NetscapeCertType.
> They can also rely on CertificatePolicies (which they do for EV certificates,
> and are starting to do for DV/OV).
> 

When this issue has come up before CertificatePolicies has often been mentioned
as an option but without many details.

How would this work in practice?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.

From mrex@sap.com  Wed Feb 20 09:42:48 2013
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 4F1AA21F8886 for ; Wed, 20 Feb 2013 09:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.234
X-Spam-Level: 
X-Spam-Status: No, score=-10.234 tagged_above=-999 required=5 tests=[AWL=0.015, 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 S6v-PjoPuOFj for ; Wed, 20 Feb 2013 09:42:47 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 27E1F21F8887 for ; Wed, 20 Feb 2013 09:42:46 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r1KHf8wL005709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Feb 2013 18:41:09 +0100 (MET)
In-Reply-To: 
To: Stefan Santesson 
Date: Wed, 20 Feb 2013 18:41:08 +0100 (CET)
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: <20130220174108.C7D301A5A7@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: pkix 
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 17:42:48 -0000

Stefan Santesson wrote:
>
> The present case is as far as I can see a complete deadlock.
> Nor ITU/ISO nor PKIX can change the meaning of EKU, neither can
> implementers do what they feel they need to do without breaking/stretching
> the standard.

I'm seeing flawed assumptions about the protocol feature EKU
in several places: some large companies, PKIX(IETF) and ITU/ISO.

First of all, the stuff that is defined to be processed along the
certification path (i.e. within the certficate path validation function)
are name constraints, the path length constraint of BasicConstraints,
certificate policies and certificate policy constraints.

With few exceptions EKU is a mostly useless attribute, for which the
interpretation is left _entirely_ up to the calling application --
and calling applications often ignore it (or need to do so, per spec).

rfc5280 section 6.1 does not specify processing of EKUs anywhere
-- 6.1.4 (n) is limited to processding the KeyUsage certSign,
and 6.3.3 (f) is limited to processing the KeyUsage crlSign,
and 6.1 explicitly RECOMMENDs against performing conformance
checks for stuff described in Section 4 & 5 of rfc5280.

The path validation function also does not have an input of the type
"intended key usage", so there is really nothing that the path validation
function could do about application usage.


Although there exist a few EKU definitions in rfc5280:
http://tools.ietf.org/html/rfc5280#page-45

not all of them are actually used.  id-kp-timeStamping is required
by rfc3151-Timestamps, id-kp-OCSPSigning might be used in some
places for dedicated OCSP signers (that differ from the cert issuer),
and id-kp-emailProtection might be used by some S/Mime implementations.


Two fairly useless EKUs seem to be:

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
   -- TLS WWW client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

Above two EKUs are unknown to all versions of TLS (rfc2246-rfc5246)
**AND** unknown to the HTTP-over-TLS spec rfc2818.  Unlike the PKIX
definition of these two EKUs, usage of TLS isn't limited to
HTTP-over-TLS anyway, so these two EKUs are pretty useless with the
existing specs.


Properly defined EKU usage in app protocols seem to exist only for

id-kp-OCSPSigning      http://tools.ietf.org/html/rfc2560#section-4.2.2.2
id-kp-timeStamping     http://tools.ietf.org/html/rfc3161#section-2.3
id-kp-emailProtection  http://tools.ietf.org/html/rfc3850#section-4.4.4
                       http://tools.ietf.org/html/rfc5750#section-4.4.4

(however, it was undefined in S/Mime 2 and S/Mime 3.0, so it must be
 ignored when backwards interop is desired).


-Martin

From mstjohns@comcast.net  Wed Feb 20 09:57:49 2013
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 9DC9C21F8798 for ; Wed, 20 Feb 2013 09:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.271
X-Spam-Level: 
X-Spam-Status: No, score=-100.271 tagged_above=-999 required=5 tests=[AWL=0.167, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvgDPs50ts8m for ; Wed, 20 Feb 2013 09:57:48 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id ACA9321F8759 for ; Wed, 20 Feb 2013 09:57:43 -0800 (PST)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2dU41l0091wpRvQ53hxjih; Wed, 20 Feb 2013 17:57:43 +0000
Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta18.westchester.pa.mail.comcast.net with comcast id 2hxi1l00h2kB7pQ3ehxj2o; Wed, 20 Feb 2013 17:57:43 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 20 Feb 2013 12:57:45 -0500
To: Dr Stephen Henson ,pkix@ietf.org
From: Michael StJohns 
In-Reply-To: <5124FFCD.8010405@drh-consultancy.co.uk>
References: <5123E0C7.5020506@bbn.com>    <5124FFCD.8010405@drh-consultancy.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361383063; bh=uArOaca3b76y4BcDleY/qVIuaEIyQxfABvJHu8H/kio=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=pehpA2Eq51nf9p6CVC+P6JtKwJNJF82KL8uRLRXxwNlsUW0gHjK86CMemsdOH6kpX dmTJ7tcl39LE8voHI5SBqdQIids+dHLqA2E6waFdlSPcv81QSLu3CpyEjdC5bs+vfa FOKAZ2FMuX8NLUgk+TYG5qFkW87Vzootd27EQw3A0L9tpWcLXT+nxeMu7nKIAjLtHA ZNXhMXBORovSPg9zGsrmq27g7A8NyxO7d7ES1PhXxA50hcX2Yx/XhXt8NxOCMjxOup 5IdUzfYiajdhNDDu7uNnn0d2vgW8fcGMddQyer4MHjcLW6klEJBOzh099Kl3XP/SZQ 8YhWfdg01uIDg==
Message-Id: <20130220175747.ACA9321F8759@ietfa.amsl.com>
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 17:57:49 -0000

At 11:54 AM 2/20/2013, Dr Stephen Henson wrote:
>On 20/02/2013 16:26, Erwann Abalea wrote:
>> 
>> They can define their own extension, like MS ApplicationPolicy, or NetscapeCertType.
>> They can also rely on CertificatePolicies (which they do for EV certificates,
>> and are starting to do for DV/OV).
>> 
>
>When this issue has come up before CertificatePolicies has often been mentioned
>as an option but without many details.
>
>How would this work in practice?


The simplest way would be to just use the EK usage OIDS (not the EKU cert extension OID) as "policies".  You'd have to include each and every one in all of the CA's in the chain in the policy extension (or the anyPolicy policy), but that's probably easier than defining a whole new extension and modifying the path processing algorithms to add another path-binding extension.  I'd probably also include the EK oid in the EKU of the end certificate to actually signal the cert can do what the EK oid says it can do, otherwise you get some issues where the intermediate CA has the usage bits set to sign code (for example).

A different way might be to define a "BindingExtendedKeyUsage" policy and use that in conjunction with the EKU extension to signal that the set of OIDs in an EKU must be a subset of the parents EKU OID set (and for purposes of path walking will be reduced to a subset during evaluation).  Unfortunately, the semantics of the policy extension are more in tune with turning on things (e.g. if policy A is present in the chain then you get treated better) than turning off things.  In this case, you'd have to change the meaning of the policy to say that if its present in any parent then the path processing has to do the "binding key usage" processing to that parent, otherwise the last CA in the path can just decline to place the policy in the cert it issues.

But I'd like to note that this treatment of EKs as a general class is pretty short sighted.  There are few if any key usages that you really want to control from the root, and those are more properly handled as part of the path processing implementation based on the chain characteristics, rather than trying to do something like general path-like processing for the EKU based on the parent CA.

E.g. if the attributes for the trust anchor for this chain says that the chain can't be used for signing code, then the presence of the appropriate code signing EK oid is ignored.


>Steve.
>-- 
>Dr Stephen N. Henson.
>Core developer of the   OpenSSL project: http://www.openssl.org/
>Freelance consultant see: http://www.drh-consultancy.co.uk/
>Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.
>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix



From mstjohns@comcast.net  Wed Feb 20 10:09:32 2013
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 1064021F871E for ; Wed, 20 Feb 2013 10:09:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.294
X-Spam-Level: 
X-Spam-Status: No, score=-100.294 tagged_above=-999 required=5 tests=[AWL=0.143, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7rRvd+S27BA for ; Wed, 20 Feb 2013 10:09:31 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6F43021F8718 for ; Wed, 20 Feb 2013 10:09:31 -0800 (PST)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2dKz1l00L1swQuc53i9Xzt; Wed, 20 Feb 2013 18:09:31 +0000
Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta15.westchester.pa.mail.comcast.net with comcast id 2i9V1l00q2kB7pQ3bi9WoD; Wed, 20 Feb 2013 18:09:31 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 20 Feb 2013 13:09:32 -0500
To: mrex@sap.com,Stefan Santesson 
From: Michael StJohns 
In-Reply-To: <20130220174108.C7D301A5A7@ld9781.wdf.sap.corp>
References:  <20130220174108.C7D301A5A7@ld9781.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361383771; bh=EiEsGaiCWZLEEEdrHOak82uSQqM5sKYffzecO20lrgM=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=ii2s8UV2tgpwCL9XpvL2PhiXQ73TixuIthxdb+/6rkEIRIXtKhFjK1kQKl9AefWy9 ISmY9QNZd5EVIrPxmeUxeHw1UqcolBIk3+z6rlw5SFIeUHUr4HMddqbZo5ipGtqQYv OHhkmm5xcqWQeeK2KMFDF+Url6St5d4GO02eV2GjVj9WECf2iEhGb/sIqSEJESXqFK HIxXCYMYpqjCdnIrpPNHj3alBJSqdL19b4JMFcDzKkjWGxXrSp+Mix2/jbPuXY13Bg mk5feUJE3AA3hDUwv0A9QcqNkluki0g+RTYnWInlB6qS66To4fT8YbdQqRmb6WR1hz ZQxAbHhMA24jQ==
Message-Id: <20130220180931.6F43021F8718@ietfa.amsl.com>
Cc: pkix 
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 18:09:32 -0000

At 12:41 PM 2/20/2013, Martin Rex wrote:
>   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
>   -- TLS WWW client authentication
>   -- Key usage bits that may be consistent: digitalSignature
>   -- and/or keyAgreement

I've actually used this EK oid for client certificates for TLS.  The general code for accepting (and deriving user credentials from) client certificates is mostly useless.  

I've ended up getting the raw certificate (after path processing validates the basics) and pulling it apart to see if it has what I want.  This works well when you have a standard mapping from a cert/cert chain to a user credential, but you want to make sure that you aren't  - for example - accepting an email credential.

(You can't do this without writing additional processing code: I want to accept a cert that's no more than 1 CA below a known and specific root, and I want to take the UID field from the subject name of the cert as the handle for mapping the cert to the server user/role and I want this cert to be a TLS cert, any other cert that chains to one of my acceptable roots gets the guest credential and role)

Mike



From hotz@jpl.nasa.gov  Wed Feb 20 11:01:50 2013
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 3211A21F8A06 for ; Wed, 20 Feb 2013 11:01:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.044
X-Spam-Level: 
X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555,  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 gpy7QRFuBiFn for ; Wed, 20 Feb 2013 11:01:49 -0800 (PST)
Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id A8B1E21F89D8 for ; Wed, 20 Feb 2013 11:01:49 -0800 (PST)
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 r1KJ1avC009732 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 20 Feb 2013 11:01:37 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Henry B. Hotz" 
In-Reply-To: <20130220180931.6F43021F8718@ietfa.amsl.com>
Date: Wed, 20 Feb 2013 11:01:37 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <3FA026A6-58AB-40F6-9DCE-B8E70F2B6DED@jpl.nasa.gov>
References:  <20130220174108.C7D301A5A7@ld9781.wdf.sap.corp> <20130220180931.6F43021F8718@ietfa.amsl.com>
To: Michael StJohns 
X-Mailer: Apple Mail (2.1499)
X-Source-Sender: hotz@jpl.nasa.gov
X-AUTH: Authorized
Cc: Stefan Santesson , pkix 
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 19:01:50 -0000

If you replace "1 below" with "n below" this strikes me as a really =
common use case.  It's a pity the standards don't address it clearly =
enough that standard software handles it more easily.

On Feb 20, 2013, at 10:09 AM, Michael StJohns  =
wrote:

> At 12:41 PM 2/20/2013, Martin Rex wrote:
>>  id-kp-clientAuth             OBJECT IDENTIFIER ::=3D { id-kp 2 }
>>  -- TLS WWW client authentication
>>  -- Key usage bits that may be consistent: digitalSignature
>>  -- and/or keyAgreement
>=20
> I've actually used this EK oid for client certificates for TLS.  The =
general code for accepting (and deriving user credentials from) client =
certificates is mostly useless. =20
>=20
> I've ended up getting the raw certificate (after path processing =
validates the basics) and pulling it apart to see if it has what I want. =
 This works well when you have a standard mapping from a cert/cert chain =
to a user credential, but you want to make sure that you aren't  - for =
example - accepting an email credential.
>=20
> (You can't do this without writing additional processing code: I want =
to accept a cert that's no more than 1 CA below a known and specific =
root, and I want to take the UID field from the subject name of the cert =
as the handle for mapping the cert to the server user/role and I want =
this cert to be a TLS cert, any other cert that chains to one of my =
acceptable roots gets the guest credential and role)
>=20
> Mike
>=20
>=20
> _______________________________________________
> 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 stefan@aaa-sec.com  Wed Feb 20 11:22:50 2013
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 3391821F88C7 for ; Wed, 20 Feb 2013 11:22:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.721
X-Spam-Level: 
X-Spam-Status: No, score=-100.721 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_QP_LONG_LINE=1.396, 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 f5TzgY41PyBA for ; Wed, 20 Feb 2013 11:22:49 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 10AB121F8798 for ; Wed, 20 Feb 2013 11:22:48 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id CC39F4223A7 for ; Wed, 20 Feb 2013 20:22:46 +0100 (CET)
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 NFNtFxXHOh_O for ; Wed, 20 Feb 2013 20:22:46 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 5981442235F for ; Wed, 20 Feb 2013 20:22:46 +0100 (CET)
Received: (qmail 79463 invoked from network); 20 Feb 2013 19:22:45 -0000
Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.208]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 20 Feb 2013 19:22:45 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Wed, 20 Feb 2013 20:22:43 +0100
From: Stefan Santesson 
To: pkix 
Message-ID: 
Thread-Topic: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3444236566_8351895"
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 19:22:50 -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_3444236566_8351895
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Again I'm not here to defend MSFT, but I can shead some light about the
rationale.

Don't make the mistake to believe that this was done by ignorant people with
no respect for standards.
Nor assume that they were to lazy to come up with their own extension and
such.

This was introduced well over 10 years ago and I truly believe that the
engineers at the time did their best and thought they did the right thing.
They did try their own extension, but that is a rocky road. MSFT tried with
ApplicationPolicy. But it didn't do the job. Presumably because no once
cared to implement it besides Microsoft.
Certificate policy does not work either. As we at that time discovered the
hard way, certificate policy implementations are terribly broken.
A huge amount of PKI:s put policies in CA certificates that has nothing to
do with the constraining mechanism defined in X.509 and RFC 5280 path
processing.

As deployments as they are effectively prevents standards compliant path
processing of policies, the result is that no one really checks policies as
per 5280 path processing, and if they do, they don't use the resulting
policy set for anything useful.
As a result, no one discover their error and corrects it. And the problems
goes on and on forever.

/Stefan


From:  Erwann Abalea 
Date:  Wednesday, February 20, 2013 5:26 PM
To:  Piyush Jain 
Cc:  Stefan Santesson , pkix 
Subject:  Re: [pkix] A non-compliant use of the EKU extension in Mozilla's
CA Certificate Policy Version 2.1.

> 
> 2013/2/20 Piyush Jain 
>> 
>> really?
>> 
>>  implementers can choose to define another eku like extension with a
>> different OID. it does not break the standards and serves their need.
>> Their attitude will change only when their customers start complaining that
>> their products are cannot inter operate with others because they don't follow
>> the standards.
> 
> They can define their own extension, like MS ApplicationPolicy, or
> NetscapeCertType.
> They can also rely on CertificatePolicies (which they do for EV certificates,
> and are starting to do for DV/OV).
> 
> -- 
> Erwann. _______________________________________________ pkix mailing list
> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix



--B_3444236566_8351895
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable


Again I'm not here to defend=
 MSFT, but I can shead some light about the rationale.

<=
div>Don't make the mistake to believe that this was done by ignorant people =
with no respect for standards.
Nor assume that they were to lazy t=
o come up with their own extension and such.

This w=
as introduced well over 10 years ago and I truly believe that the engineers =
at the time did their best and thought they did the right thing.
T=
hey did try their own extension, but that is a rocky road. MSFT tried with A=
pplicationPolicy. But it didn't do the job. Presumably because no once cared=
 to implement it besides Microsoft.
Certificate policy does not wo=
rk either. As we at that time discovered the hard way, certificate policy im=
plementations are terribly broken.
A huge amount of PKI:s put poli=
cies in CA certificates that has nothing to do with the constraining mechani=
sm defined in X.509 and RFC 5280 path processing.

A=
s deployments as they are effectively prevents standards compliant path proc=
essing of policies, the result is that no one really checks policies as per =
5280 path processing, and if they do, they don't use the resulting policy se=
t for anything useful.
As a result, no one discover their error an=
d corrects it. And the problems goes on and on forever.

=

/Stefan


=
From:  Erwann Abalea <eabalea@g=
mail.com>
Date:  Wednesday, =
February 20, 2013 5:26 PM
To:  Piyu=
sh Jain <piyush@ditenity.com>=

Cc:  Stefan Santesson <stefan@aaa-sec.com>, pkix <pkix@ietf.org>
=
Subject:  Re: [pkix] A non-compliant use of the EKU extension in Mozi=
lla's CA Certificate Policy Version 2.1.


2013/2/20 P=
iyush Jain <piyush@ditenity.com>
r=
eally?
 implementers can choose to define another eku like extension w=
ith a different OID. it does not break the standards and serves their need.<=
br>
Their attitude will change only when their customers start complaining that=
 their products are cannot inter operate with others because they don't foll=
ow the standards.
They can define their own exten=
sion, like MS ApplicationPolicy, or NetscapeCertType.
They can als=
o rely on CertificatePolicies (which they do for EV certificates, and are st=
arting to do for DV/OV).

-- 
Erwann.
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/m=
ailman/listinfo/pkix


--B_3444236566_8351895--



From pgut001@cs.auckland.ac.nz  Wed Feb 20 15:44:15 2013
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 7BDB721F8880 for ; Wed, 20 Feb 2013 15:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.419
X-Spam-Level: 
X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180,  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 bBfLeoX6hZ4c for ; Wed, 20 Feb 2013 15:44:14 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 876A421F884F for ; Wed, 20 Feb 2013 15:44:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1361403853; x=1392939853; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=eFL3+QVTTp/FYl1qkhBU7mAclPpb39Tr3fA/puLsaTs=; b=hKwcvqtYyiwbMqZhBBfxbIEW02agYC+9vF1eNxqqevNonsCFUA+ibgfk wGjdVQNixtrePXiLWVTysslNHtwqZ1yThsERsRblUKtH/DX4q3j5RZikP 5v7kiUxnwbSwnyg3IuaWJ2VB4yZbcPB6zU/R/iAS5Bdg2N4lN9PhmV7PX A=;
X-IronPort-AV: E=Sophos;i="4.84,705,1355050800"; d="scan'208";a="171425726"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Feb 2013 12:44:10 +1300
Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Feb 2013 12:44:09 +1300
Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.108]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 12:44:09 +1300
From: Peter Gutmann 
To: IETF PKIX 
Thread-Topic: [pkix] purpose of LDAP in PKI
Thread-Index: Ac4PxC2XVZKFodDuR6as29Mr2Oi+kQ==
Date: Wed, 20 Feb 2013 23:44:09 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C733340EFE7@uxcn10-2.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] purpose of LDAP in PKI
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, 20 Feb 2013 23:44:15 -0000

Phillip Hallam-Baker  writes:=0A=
=0A=
>What was never finished was the one mechanism that a client can apply to=
=0A=
>translate an SMTP email recipient address to the corresponding S/MIME=0A=
>configuration (including cert).=0A=
=0A=
https://financialcryptography.com/mt/archives/000966.html=0A=
=0A=
(OK, so it'd need to be written up as an RFC).=0A=
=0A=
Peter.=0A=

From pgut001@cs.auckland.ac.nz  Wed Feb 20 15:53:32 2013
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 36F2621E8030 for ; Wed, 20 Feb 2013 15:53:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Level: 
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174,  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 zV7ehUohAcvW for ; Wed, 20 Feb 2013 15:53:31 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD7521F86EC for ; Wed, 20 Feb 2013 15:53:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1361404410; x=1392940410; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=zZDKKo4WZwxyto2BzvoSF5Pwka/hQoqqqQBMk0TS/+c=; b=gaTbJ6AtcUSw/oNex3nBku41Gb3v2aYBiE6YsyzuBX2rLrcykbyWmEZy HtVBYSmuEK6RTg7k3Vd+mIqJSKhNdCGPBhxkJRVzRtbpv1hu7jufArFf9 liy8Kt3EpVcyWb3HpM5HttrAUOmqDuPARmGqO7P1cncwuHzrkkSBIE+IE c=;
X-IronPort-AV: E=Sophos;i="4.84,705,1355050800"; d="scan'208";a="171427506"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Feb 2013 12:53:20 +1300
Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.108]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 12:53:19 +1300
From: Peter Gutmann 
To: IETF PKIX 
Thread-Topic: [pkix] A non-compliant use of the EKU extension in Mozilla's CA  Certificate Policy Version 2.1.
Thread-Index: Ac4PxXWooc8wkjG9QW61eQS2vZ/m2w==
Date: Wed, 20 Feb 2013 23:53:19 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C733340EFFC@uxcn10-2.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 20 Feb 2013 23:53:32 -0000

Denis Pinkas  writes:=0A=
=0A=
>I believe that you are missing a point in the standardization process: onc=
e=0A=
>an OID has been defined, its semantics CANNOT be changed.=0A=
=0A=
So this means almost every bit of text since RFC 2459 is invalid or illegal=
 or=0A=
whatever happens when you change the semantics of an OID?  There are OIDs f=
or=0A=
all sorts of things in there that have been modified and adapted in every R=
FC=0A=
since then.=0A=
=0A=
>Thus the reality is not the one you describe, but the fact that large=0A=
>companies are ignoring standards and it is time to let them understand tha=
t=0A=
>the software they provide is not compliant with the standards.=0A=
=0A=
Lest the hand of God come down and smite them, because we all know how=0A=
seriously God takes standards.=0A=
=0A=
Peter.=

From pgut001@cs.auckland.ac.nz  Wed Feb 20 16:01:07 2013
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 591C221F8C51 for ; Wed, 20 Feb 2013 16:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.43
X-Spam-Level: 
X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169,  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 Rz3JOhdxWbDB for ; Wed, 20 Feb 2013 16:01:06 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 77FD021F8C4F for ; Wed, 20 Feb 2013 16:01:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1361404866; x=1392940866; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=VIGDyxZ105ZuzQJ47zgem2LERJlNtAeW9Wo3CfC00jo=; b=hjJOA7s7dFslIRqAZqMtq5vjFSld62y5oNPLj8owsWjzWV2FXlbyLBRK UgegiTvqrELHHYrYNgx3VZTcKD0bhXQZk0yjfHaxYytzDuQijoyFaseBm CkUeyFfCQ4PfyeRHzaAYKKjnjuc8a5/doC/ST4QJAp7zyGk2QgMTQlIDp c=;
X-IronPort-AV: E=Sophos;i="4.84,705,1355050800"; d="scan'208";a="171428650"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Feb 2013 13:01:06 +1300
Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe1.UoA.auckland.ac.nz (130.216.4.112) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 21 Feb 2013 13:01:05 +1300
Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.108]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 13:01:05 +1300
From: Peter Gutmann 
To: IETF PKIX 
Thread-Topic: [pkix] A non-compliant use of the EKU extension in Mozilla's CA  Certificate Policy Version 2.1.
Thread-Index: Ac4Pxor0duve3zIaQDOJCkdRvCQKgw==
Date: Thu, 21 Feb 2013 00:01:04 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C733340F00F@uxcn10-2.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 21 Feb 2013 00:01:07 -0000

Martin Rex  writes:=0A=
=0A=
>Properly defined EKU usage in app protocols seem to exist only for=0A=
>=0A=
>[...]=0A=
>id-kp-emailProtection  http://tools.ietf.org/html/rfc3850#section-4.4.4=0A=
>                       http://tools.ietf.org/html/rfc5750#section-4.4.4=0A=
>=0A=
>(however, it was undefined in S/Mime 2 and S/Mime 3.0, so it must be ignor=
ed=0A=
>when backwards interop is desired).=0A=
=0A=
emailProtection is vague enough to be useless as well, since in crypto term=
s=0A=
it means "any usage at all (signing, encryption, keyAgreement) as long as=
=0A=
email is involved somewhere".  For example a certificate that handles licen=
se=0A=
management for a spam-filtering appliance could be designated as being for=
=0A=
emailProtection even though it's never actually used for sending, receiving=
,=0A=
or processing email.=0A=
=0A=
Peter.=0A=

From ynir@checkpoint.com  Wed Feb 20 23:47:20 2013
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 55F6E21F8DC7 for ; Wed, 20 Feb 2013 23:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.562
X-Spam-Level: 
X-Spam-Status: No, score=-10.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 yOi+zICQxfUg for ; Wed, 20 Feb 2013 23:47:19 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6D521F8DC3 for ; Wed, 20 Feb 2013 23:47:18 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r1L7lCY2016254; Thu, 21 Feb 2013 09:47:12 +0200
X-CheckPoint: {5125CC6F-0-1B221DC2-2FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Thu, 21 Feb 2013 09:47:12 +0200
From: Yoav Nir 
To: Denis Pinkas 
Thread-Topic: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
Thread-Index: Ac4PAwrGiY2upjI+cEqEChmHsLyOkwAZcu6AACOC5oA=
Date: Thu, 21 Feb 2013 07:47:11 +0000
Message-ID: 
References: <9A043F3CF02CD34C8E74AC1594475C733340E7BB@uxcn10-2.UoA.auckland.ac.nz> <5124E2AB.5020400@bull.net>
In-Reply-To: <5124E2AB.5020400@bull.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.199]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1E66B67F375A3B4E96909BC49BAB1C5A@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 21 Feb 2013 07:47:20 -0000

There's an issue here of what the role of an SDO.

You can take the approach that the SDO is in charge of the technology. In t=
hat case, no certificate is valid for the Internet unless it is compliant w=
ith an RFC issued by the PKIX working group. That's a nice model, and one w=
here the needs of multiple stakeholders will be taken into consideration. B=
ut this can and does lead to a disconnect between the standards and the pra=
ctice.

Another approach is that the SDO does not define the standard, but rather i=
t captures the standard, whether that standard was set by a big vendor impl=
ementing it or by some people on a mailing list reaching rough consensus. O=
f course, big vendor doesn't need the standard, but it really helps the oth=
er stakeholders catch up.

10 years ago, the browser market was dominated by Internet Explorer, and so=
me of the HTML features it supported were not standardized. Despite the eff=
orts of W3C, web sites optimized their HTML for IE, which left the other br=
owsers at a significant disadvantage. In the end, the tides turned, the mar=
ket dominance is gone, and websites are now written to standards so that th=
ey work with all browsers, although we are seeing a similar issue with WebK=
it on the mobile platforms.

If SDOs were to document IE's behavior rather than stick to their own visio=
n of how HTML should be, it would have been easier for the other browsers t=
o work with all sites, instead of relying on reverse engineering. It's even=
 possible that the dominance of IE would have gone away earlier.=20

This sounds bad, like an SDO rubber-stamping what the big vendor has done. =
It's especially bad in hindsight, because in the end the little guys (if yo=
u can consider Google and Mozilla "little guys") won, and the pure vision o=
f HTML standards triumphed. It could have ended very differently, though.

Yoav

On Feb 20, 2013, at 4:50 PM, Denis Pinkas  wrote:

> Peter,
>=20
> I believe that you are missing a point in the standardization process:
> once an OID has been defined, its semantics CANNOT be changed.
>=20
> You will also notice that the OID for EKU has NOT been assigned by the IE=
TF, but by ISO/ ITU-T.
> So PKIX is unable to make any change in the semantics, and it is the same=
 for ISO/ITU-T even
> with the best will.
>=20
> I do not think it would be reasonable to change the semantics of what an =
OID is.
>=20
> Thus the reality is not the one you describe, but the fact that large com=
panies are ignoring standards and
> it is time to let them understand that the software they provide is not c=
ompliant with the standards.
>=20
> Denis
>=20
>> Stephen Kent  writes:
>>=20
>>> I think it unfortunate that Mozilla is advising folks to use EKU in a f=
ashion
>>> that is not supported by X.509 or 5280. (Specifically, a compliant RP s=
hould
>>> not reject a subordinate cert based on an EKU value encountered in a CA=
 cert
>>> higher in a cert path.)
>> The other way of looking at it is that it's unfortunate that PKIX refuse=
s to
>> standardise a widely-used and -adopted practice.  As Stefan pointed out,=
 this
>> is just another case of reality vs. PKIX, reality will keep being what i=
t is
>> and PKIX will keep going down its own path, unconstrained by reality.
>>=20
>> Peter.
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>=20
>=20
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>=20
> Email secured by Check Point


From eabalea@gmail.com  Thu Feb 21 01:36:41 2013
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 24E3121F8E2A for ; Thu, 21 Feb 2013 01:36:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.198
X-Spam-Level: 
X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=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 OnFjN5sqgBBz for ; Thu, 21 Feb 2013 01:36:40 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 60F1721F8DE9 for ; Thu, 21 Feb 2013 01:36:39 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id n8so6719478lbj.31 for ; Thu, 21 Feb 2013 01:36:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2fbvtKK25T99N3sVxnHmHf2YVskzhCahDs4b6iTDlAs=; b=DugL0tRvP6cufBc/cGP6o0Kp5JhB4ImubyPtaEQT3ffx+tdO+wZDy0DLml8D88Jsvb 1uW+HLdqmSzCvhWI1eSgFOqIVYc7Sy4X8O1eFf90ihhz70lAcYCMNbOgIjtdud9bX0Ng JPXq7kqCXQM3RMf/p1ppc+npBfxO35OZoh4CSY1l7bZz1OZh/v08TaEYLwNyC7c2tM+E xSIjYi3gxGbbgVl76e4+KJlBQInGCzhSFzZztC+vUjtK2dO6lZt6DMUBgNC7v9MRNqen 8FD3GK/SgidXsYpmswuNCGLWgeXTk6lZt/WTkXy7SelEGlGUzPN3NCiRAtXyPlmjpCvD MFPQ==
MIME-Version: 1.0
X-Received: by 10.112.51.34 with SMTP id h2mr10028638lbo.39.1361439398248; Thu, 21 Feb 2013 01:36:38 -0800 (PST)
Received: by 10.114.29.1 with HTTP; Thu, 21 Feb 2013 01:36:38 -0800 (PST)
In-Reply-To: 
References:  
Date: Thu, 21 Feb 2013 10:36:38 +0100
Message-ID: 
From: Erwann Abalea 
To: Stefan Santesson 
Content-Type: multipart/alternative; boundary=f46d0421a95bb7532e04d638cf17
Cc: pkix 
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 21 Feb 2013 09:36:41 -0000

--f46d0421a95bb7532e04d638cf17
Content-Type: text/plain; charset=UTF-8

2013/2/20 Stefan Santesson 
>
> This was introduced well over 10 years ago and I truly believe that the
> engineers at the time did their best and thought they did the right thing.
> They did try their own extension, but that is a rocky road. MSFT tried
> with ApplicationPolicy. But it didn't do the job. Presumably because no
> once cared to implement it besides Microsoft.
> Certificate policy does not work either. As we at that time discovered the
> hard way, certificate policy implementations are terribly broken.
>

Then PKITS came, with some sets of tests on CertificatePolicies. I hope
that by now, major tookits (NSS/libpkix, MSCAPI, OpenSSL, ...) validates
all the tests.


> A huge amount of PKI:s put policies in CA certificates that has nothing to
> do with the constraining mechanism defined in X.509 and RFC 5280 path
> processing.
>

That's sadly true.

As deployments as they are effectively prevents standards compliant path
> processing of policies, the result is that no one really checks policies as
> per 5280 path processing, and if they do, they don't use the resulting
> policy set for anything useful.
>

Policies are checked for EV validation, and may be (in the future) for DV
and OV as well.
I don't know if the performed validation is RFC5280 compliant.

Anyway, between modifying EKU semantics for a browser + asking all CAs to
update their subordinate CAs, and correctly implementing policies path
processing, which way is better?

-- 
Erwann.

--f46d0421a95bb7532e04d638cf17
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


2013/2/20 Stefan Santesson <stefan@aaa-sec=
.com>


This was introduced well over 10 years ago and I truly believe =
that the engineers at the time did their best and thought they did the righ=
t thing.


They did try their own extension, but that is a rocky road. MSFT tried=
 with ApplicationPolicy. But it didn't do the job. Presumably because n=
o once cared to implement it besides Microsoft.
Certificate polic=
y does not work either. As we at that time discovered the hard way, certifi=
cate policy implementations are terribly broken.



Then PKITS came, with some sets of t=
ests on CertificatePolicies. I hope that by now, major tookits (NSS/libpkix=
, MSCAPI, OpenSSL, ...) validates all the tests.
=C2=A0


A huge amount of PKI:s put policies in CA certificates that has=
 nothing to do with the constraining mechanism defined in X.509 and RFC 528=
0 path processing.



That's sadly true.


As deployments as they are effectively prevents standards compliant pa=
th processing of policies, the result is that no one really checks policies=
 as per 5280 path processing, and if they do, they don't use the result=
ing policy set for anything useful.



Policies are checked for EV validati=
on, and may be (in the future) for DV and OV as well.
I don't=
 know if the performed validation is RFC5280 compliant.



Anyway, between modifying EKU semantics for a browser + asking all CAs=
 to update their subordinate CAs, and correctly implementing policies path =
processing, which way is better?

-- 
Erwann.

--f46d0421a95bb7532e04d638cf17--

From stefan@aaa-sec.com  Thu Feb 21 02:57:33 2013
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 D29A821F8E46 for ; Thu, 21 Feb 2013 02:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.979
X-Spam-Level: 
X-Spam-Status: No, score=-100.979 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 JEFaJySttndT for ; Thu, 21 Feb 2013 02:57:33 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 9F02221F8DB7 for ; Thu, 21 Feb 2013 02:57:31 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id DD81542CECE for ; Thu, 21 Feb 2013 11:57:29 +0100 (CET)
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 WhylLJChD3ct for ; Thu, 21 Feb 2013 11:57:29 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 7DFC242CEEA for ; Thu, 21 Feb 2013 11:57:29 +0100 (CET)
Received: (qmail 97162 invoked from network); 21 Feb 2013 10:57:29 -0000
Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.208]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 21 Feb 2013 10:57:29 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Thu, 21 Feb 2013 11:57:30 +0100
From: Stefan Santesson 
To: Erwann Abalea 
Message-ID: 
Thread-Topic: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3444292654_11730513"
Cc: pkix 
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 21 Feb 2013 10:57:33 -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_3444292654_11730513
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

From:  Erwann Abalea 
> Anyway, between modifying EKU semantics for a browser + asking all CAs to
> update their subordinate CAs, and correctly implementing policies path
> processing, which way is better?

It's not just a matter of what is better. It is a matter of what will happen
and what works.
Asking CAs to update their CA certs does no good unless they actually do it.
And that is extremely unlikely.

Sometimes I sense that standards groups slip away from a perception of what
their role is.

The standards body is not a legal institution proclaiming any rules that
product developers must follow.
The standards body produces specifications that implementers MAY use if and
wen they see any benefits in using them.

The crime committed by an implementer that ignores a standard is not
committed against the standards body, but (if at all) against its customers
and possibly towards other implementers.

So if you ask me, we should offer the implementers and stakeholders a place
to resolve the issues in a way that best serves the community.
These are matters that can't be resolved in a way that everybody is happy
with.

/Stefan



--B_3444292654_11730513
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable


From: =
 Erw=
ann Abalea <eabalea@gmail.com><=
/div>
Anyway, between modifying EKU=
 semantics for a browser + asking all CAs to update their subordinate CAs, a=
nd correctly implementing policies path processing, which way is better?

It's not just a matter of what is=
 better. It is a matter of what will happen and what works.
Asking=
 CAs to update their CA certs does no good unless they actually do it. And t=
hat is extremely unlikely.

Sometimes I sense that s=
tandards groups slip away from a perception of what their role is.

The standards body is not a legal institution proclaiming an=
y rules that product developers must follow.
The standards body pr=
oduces specifications that implementers MAY use if and wen they see any bene=
fits in using them.

The crime committed by an imple=
menter that ignores a standard is not committed against the standards body, =
but (if at all) against its customers and possibly towards other implementer=
s.

So if you ask me, we should offer the implemente=
rs and stakeholders a place to resolve the issues in a way that best serves =
the community.
These are matters that can't be resolved in a way t=
hat everybody is happy with.

/Stefan


--B_3444292654_11730513--



From peter.sylvester@edelweb.fr  Thu Feb 21 03:51:13 2013
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 DA98C21F8DDA for ; Thu, 21 Feb 2013 03:51:12 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rscuKBBVgWQ for ; Thu, 21 Feb 2013 03:51:11 -0800 (PST)
Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 705AA21F8DCA for ; Thu, 21 Feb 2013 03:51:10 -0800 (PST)
Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id 42E715E0E0 for ; Thu, 21 Feb 2013 12:49:33 +0100 (CET)
Received: from mail1.on-x.com (mail1.on-x.com [192.168.10.66]) by mx1.on-x.com (Postfix) with ESMTP id 32FD75E0DF for ; Thu, 21 Feb 2013 12:49:33 +0100 (CET)
Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id DF0F55E14F for ; Thu, 21 Feb 2013 12:49:47 +0100 (CET)
Received: from smtps.on-x.com (unknown [192.168.14.66]) by mail1.on-x.com (Postfix) with ESMTP id CD9A25E14A for ; Thu, 21 Feb 2013 12:49:47 +0100 (CET)
Received: from [192.168.1.37] (unknown [82.226.189.175]) by smtps.on-x.com (Postfix) with ESMTPSA id 6362C5E0EF for ; Thu, 21 Feb 2013 12:49:22 +0100 (CET)
Message-ID: <51260A21.2080403@edelweb.fr>
Date: Thu, 21 Feb 2013 12:50:57 +0100
From: Peter Sylvester 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: pkix@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C733340E7BB@uxcn10-2.UoA.auckland.ac.nz> <5124E2AB.5020400@bull.net>
In-Reply-To: <5124E2AB.5020400@bull.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 21 Feb 2013 11:51:13 -0000

On 02/20/2013 03:50 PM, Denis Pinkas wrote:
> Peter,
>
> I believe that you are missing a point in the standardization process:
> once an OID has been defined, its semantics CANNOT be changed.
>
> You will also notice that the OID for EKU has NOT been assigned by the IETF, but by ISO/ ITU-T.
> So PKIX is unable to make any change in the semantics, and it is the same for ISO/ITU-T even
> with the best will.
>
> I do not think it would be reasonable to change the semantics of what an OID is.

Where is the conflict with X.509? There is not eveb a problem with PKIX's definitions
of concrete values IMO. In fact, PKIX has no semantics defined, just a comment
to the ASN.1 syntax.  As Peter Gutman mentioned 'email protection' means what?
There is no conflict IMO with existing specs if one would say:

- email protection means xyz. If put into and end certficate, then the cert can only
   be used for that purpose, if put into a CA cert, than this extend the path validation
   algorithm, such a CA is only supposed to issue certs that have this EKU in EE certs.




from X509:

Extended key usage extension
This field indicates one or more purposes for which the certified public key may be used, in 
addition to or in place of
the basic purposes indicated in the key usage extension field. This field is defined as follows:
extKeyUsage EXTENSION ::= {
SYNTAX SEQUENCE SIZE (1..MAX) OF KeyPurposeId
IDENTIFIED BY id-ce-extKeyUsage }
KeyPurposeId ::= OBJECT IDENTIFIER
A CA may assert any-extended-key-usage by using the anyExtendedKeyUsage identifier. This enables a 
CA to issue a
certificate that contains OIDs for extended key usages that may be required by certificate-using 
applications, without
restricting the certificate to only those key usages. If extended key usage would restrict key 
usage, then the inclusion of
this OID removes that restriction.
anyExtendedKeyUsage OBJECT IDENTIFIER ::= { 2 5 29 37 0 }[S9]
Key purposes may be defined by any organization with a need. Object identifiers used to identify key 
purposes shall be
assigned in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.
This extension may, at the option of the certificate issuer, be either critical or non-critical.
If the extension is flagged critical, then the certificate shall be used only for one of the 
purposes indicated.
If the extension is flagged non-critical, then it indicates the intended purpose or purposes of the 
key, and may be used in
finding the correct key/certificate of an entity that has multiple keys/certificates. If this 
extension is present, and the
certificate-using system recognizes and processes the extendedKeyUsage extension type, then the 
certificate-using
system shall ensure that the certificate shall be used only for one of the purposes indicated. 
(Using applications may
nevertheless require that a particular purpose be indicated in order for the certificate to be 
acceptable to that
application.)
If a certificate contains both a critical key usage field and a critical extended key usage field, 
then both fields shall be
processed independently and the certificate shall only be used for a purpose consistent with both 
fields. If there is no
purpose consistent with both fields, then the certificate shall not be used for any purpose.
This Directory Specification defines the following key purpose that can be included in the extended 
key usage
extension. Other purposes that can also be included are defined in other specifications, such as 
IETF RFC 5280.
keyPurposes OBJECT IDENTIFIER ::= {ds 38 1}

>
> Thus the reality is not the one you describe, but the fact that large companies are ignoring 
> standards and
> it is time to let them understand that the software they provide is not compliant with the standards.
>
> Denis
>
>> Stephen Kent  writes:
>>
>>> I think it unfortunate that Mozilla is advising folks to use EKU in a fashion
>>> that is not supported by X.509 or 5280. (Specifically, a compliant RP should
>>> not reject a subordinate cert based on an EKU value encountered in a CA cert
>>> higher in a cert path.)
>> The other way of looking at it is that it's unfortunate that PKIX refuses to
>> standardise a widely-used and -adopted practice.  As Stefan pointed out, this
>> is just another case of reality vs. PKIX, reality will keep being what it is
>> and PKIX will keep going down its own path, unconstrained by reality.
>>
>> Peter.
>> _______________________________________________
>> 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 piyush@ditenity.com  Thu Feb 21 07:41:24 2013
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 98E0521F8EC1 for ; Thu, 21 Feb 2013 07:41:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-1.799, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_LT4=0.442, RDNS_DYNAMIC=0.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 Llo4Mj9FmG-R for ; Thu, 21 Feb 2013 07:41:24 -0800 (PST)
Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id EE97021F8EBC for ; Thu, 21 Feb 2013 07:41:23 -0800 (PST)
Received: by mail-yh0-f54.google.com with SMTP id 29so1649828yhr.41 for ; Thu, 21 Feb 2013 07:41:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=GII+400rhwqY4/94QdNIbKBjZlJi1vkP9FO+ek6lu/E=; b=CJOEQ5888FFOLxkXmG98WeOOJ4gdnFYxbNaGpA5V25bbyOzcj/VI84QvBZ+uhj32XH 5/iDnWxXhbuRr8EjxjOOgBxEjGITjl8U5k0QMg98nDPZSGCVGMnfHIGX22YZzXK2Hcc4 B8eyR8A5GAQJ4pk3GYv427ldrLqF5Dkrxy15QHuIYS8o5z+Hg0GjkofcD3hRGew/o0c0 iiRcic7fsouaS9fsS7n/o2HVTej802MNoOqBJ2JltGs/E01HX1lOsI4kFFpX/eK0+JjF GyYGWh1IgXDQObcANz+MEhlg6TNomRY4fg5jLnvwvQmOlzAoBy0yiRGSThqkEjuXzQ6s JJQA==
X-Received: by 10.236.155.7 with SMTP id i7mr34745264yhk.16.1361461283359; Thu, 21 Feb 2013 07:41:23 -0800 (PST)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id v43sm142158252yhm.11.2013.02.21.07.41.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 Feb 2013 07:41:22 -0800 (PST)
From: "Piyush Jain" 
To: "'Peter Sylvester'" , 
References: <9A043F3CF02CD34C8E74AC1594475C733340E7BB@uxcn10-2.UoA.auckland.ac.nz> <5124E2AB.5020400@bull.net> <51260A21.2080403@edelweb.fr>
In-Reply-To: <51260A21.2080403@edelweb.fr>
Date: Thu, 21 Feb 2013 07:41:23 -0800
Message-ID: <031e01ce1049$e7f408b0$b7dc1a10$@ditenity.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFU+PKJgpk+Of64p5F/KTAfGYydCwIq0DiUAoDWZGmZUT+ecA==
Content-Language: en-us
X-Gm-Message-State: ALoCoQkIV+zPBaoPX1AKCx9b6ejGdlBt+joqnT7b3ogQDYyRbF3cQ/SdLBR9A+quLJGR+CDJ40HJ
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 21 Feb 2013 15:41:24 -0000

Where is the conflict with X.509? There is not eveb a problem with PKIX's
> definitions of concrete values IMO. In fact, PKIX has no semantics
defined,
> just a comment to the ASN.1 syntax.  As Peter Gutman mentioned 'email
> protection' means what?
> There is no conflict IMO with existing specs if one would say:
> 
> - email protection means xyz. If put into and end certficate, then the
cert can
> only
>    be used for that purpose, if put into a CA cert, than this extend the
path
> validation
>    algorithm, such a CA is only supposed to issue certs that have this EKU
in EE
> certs.
> 
The conflict is that some implementations have started deducing the extended
key usage of a certificate based on what EKU is present in other
certificates up in the chain.

Semantic of an extension with OID id-ce-extKeyUsage is clear. 5280 clearly
defines how this extension should be processed and that it applies only to
the certificate in which it is present.
What it does not defined is the meaning of objects contained within the EKU
extension because those meanings are application dependent - however this is
not the point that is being argued.

The way I see it, the purposeIDs that are defined in 5280 do not belong
there. Those definitions should have been part of application protocol
specification.

The fact that some of the purpose IDs are not being enforced by applications
has nothing to do with how applications deduce the purpose associated with a
cert.


From stefan@aaa-sec.com  Thu Feb 21 13:45:40 2013
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 A717C21E8041 for ; Thu, 21 Feb 2013 13:45:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.949
X-Spam-Level: 
X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 pF5PQYYG+dPO for ; Thu, 21 Feb 2013 13:45:40 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 16A3521E8039 for ; Thu, 21 Feb 2013 13:45:39 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 75F8E435F5B for ; Thu, 21 Feb 2013 22:45:37 +0100 (CET)
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 F3Hkp8Cp38Wd for ; Thu, 21 Feb 2013 22:45:37 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 4390B435F61 for ; Thu, 21 Feb 2013 22:45:37 +0100 (CET)
Received: (qmail 88617 invoked from network); 21 Feb 2013 21:45:36 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.105]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 21 Feb 2013 21:45:36 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Thu, 21 Feb 2013 22:45:36 +0100
From: Stefan Santesson 
To: 
Message-ID: 
Thread-Topic: Agenda items for PKIX in Orlando
In-Reply-To: <031e01ce1049$e7f408b0$b7dc1a10$@ditenity.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: [pkix] Agenda items for PKIX in Orlando
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, 21 Feb 2013 21:45:40 -0000

Please send me and Steve a note if you have anything you wish to present
at the PKIX WG in Orlando.

The slot is for 1.5 hour and we will be a bit restrictive due to the fact
that we are not allowed to take on any new work.
But we will try to use the time if there are things of interest to discuss.

/Stefan




From stefan@aaa-sec.com  Thu Feb 21 13:48:08 2013
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 4114521E808C for ; Thu, 21 Feb 2013 13:48:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.964
X-Spam-Level: 
X-Spam-Status: No, score=-101.964 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 bem3iZvnt3dg for ; Thu, 21 Feb 2013 13:48:07 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC9E21E8030 for ; Thu, 21 Feb 2013 13:48:07 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id B2369435E0A for ; Thu, 21 Feb 2013 22:48:06 +0100 (CET)
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 yswC6yphQUB5 for ; Thu, 21 Feb 2013 22:48:06 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 4BBA7435FAA for ; Thu, 21 Feb 2013 22:48:06 +0100 (CET)
Received: (qmail 94816 invoked from network); 21 Feb 2013 21:48:05 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.105]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 21 Feb 2013 21:48:05 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Thu, 21 Feb 2013 22:48:05 +0100
From: Stefan Santesson 
To: Stefan Santesson , 
Message-ID: 
Thread-Topic: [pkix] AuthContext Certificate extension
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] AuthContext Certificate 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: Thu, 21 Feb 2013 21:48:08 -0000

I have updated this draft with a full certificate example. And fixed some
nits.
If time permits I will make a short presentation of this in Orlando.

I have received some private reviews. I'm really grateful for that.
More thoughts and reviews would be much appreciated.

Thanks

/Stefan


On 2/13/13 9:02 AM, "Stefan Santesson"  wrote:

>I was made aware that the document link no longer works:
>
>Here is a link to the latest current draft:
>http://tools.ietf.org/html/draft-santesson-auth-context-extension
>
>
>Thanks to Jim for checking nits and the ASN.1 modules!
>
>/Stefan
>
>
>
>On 2/12/13 1:15 PM, "Stefan Santesson"  wrote:
>
>>I hav submitted a new draft as an individual submission:
>>
>>http://www.ietf.org/id/draft-santesson-auth-context-extension-00.txt
>>
>>Abstract
>>
>>   This document defines an extension to certificates according to
>>   [RFC5280]. The extension defined in this document holds data about
>>   how the certificate subject was authenticated by the Certification
>>   Authority who issued the certificate where this extension appears.
>>
>>   This document also defines one data structure for inclusion in this
>>   extension that designed to hold information when the subject is
>>   authenticated using a SAML assertion [SAML].
>>
>>
>>
>>
>>This draft documents an extension that we have defined in the Swedish
>>national electronic identification infrastructure in order to be able to
>>match SAML credentials with associated electronic signatures.
>>All signature certificates are issued by a central signature generation
>>service which authenticates the user using SAML credentials and then adds
>>this extension to the certificate.
>>
>>This makes it possible for service providers to compare the signer of a
>>document with the entity currently logged into the service using SAML.
>>
>>I would have loved for this to be part of the PKIX process, but as we are
>>not allowed to take on any further work, I let this do as an individual
>>submission.
>>
>>Currently the draft is based on the Swedish defined OIDs.
>>
>>There is still a short window before we need to lock this specification
>>in
>>the Swedish project, but I'm very interested in review from members of
>>this group.
>>The intention is currently to go Informational, in order to just provide
>>a
>>stable reference to this extension definition.
>>Should there be an interest in moving this to standards track, then I
>>would not object to doing so.
>>
>>/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



From turners@ieca.com  Fri Feb 22 08:55:50 2013
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 7544321F8E7B for ; Fri, 22 Feb 2013 08:55:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.835
X-Spam-Level: 
X-Spam-Status: No, score=-100.835 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_20=-0.74, 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 wDPLUuyzQK06 for ; Fri, 22 Feb 2013 08:55:48 -0800 (PST)
Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.93.35.6]) by ietfa.amsl.com (Postfix) with ESMTP id A9BCC21F8E7A for ; Fri, 22 Feb 2013 08:55:47 -0800 (PST)
Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 4EEBA65165A2A; Fri, 22 Feb 2013 10:55:39 -0600 (CST)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id E303B65165864 for ; Fri, 22 Feb 2013 10:55:38 -0600 (CST)
Received: from [108.45.16.214] (port=60312 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U8vuT-0003SM-3x for pkix@ietf.org; Fri, 22 Feb 2013 10:55:45 -0600
Message-ID: <5127A310.3000606@ieca.com>
Date: Fri, 22 Feb 2013 11:55:44 -0500
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: pkix@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; 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.45.16.214]:60312
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 3
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: [pkix] AD review of draft-ietf-pkix-rfc2560bis
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, 22 Feb 2013 16:55:50 -0000

Two things I think we should discuss and a couple of comments:

Discuss 1) s4.3: I totally agree with upgrading RSA with SHA-256 to a 
SHALL, but why are we updating RSA with SHA-1 to a SHALL?  With the 
known weaknesses, I could see leaving it at SHOULD.

Discuss 2) s4.3: The MTI algs section made me think that we need to say 
something about the key size as well.  Since we just had the same 
discussion about S/MIME not too long ago I suggest taking some text from 
RFC5751 s4.2/s4.3.

c1) In s1, it looks like a header is missing for section 1.1 or "1.1" 
should be removed from the following:

1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

c2) s2.6: r/Se further/See further

c3) s4.4.7.1: In the last paragraph r/4.4.7.1/4.4.7.2 otherwise it's a 
circular reference ;)

c4) s4.4.7.2.1: Is it clearer to say the responder should pick the 
highest precedence or the lowest numbered selection?  Just looking for 
consistency between the paragraph before the list and the one after the 
list.

spt

From hallam@gmail.com  Sat Feb 23 06:42:11 2013
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 481F121F8FA4 for ; Sat, 23 Feb 2013 06:42:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.461
X-Spam-Level: 
X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.139,  BAYES_00=-2.599, NO_RELAYS=-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 5ql3JBHn5j6H for ; Sat, 23 Feb 2013 06:42:10 -0800 (PST)
Received: from mail-we0-x22c.google.com (we-in-x022c.1e100.net [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFFB21F8FA3 for ; Sat, 23 Feb 2013 06:42:10 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id x10so1333372wey.3 for ; Sat, 23 Feb 2013 06:42:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pkVv1Ii+ejamDyoYGKNt68Z+yXaZAx8ERPHQpXs235o=; b=tNkKzpx4Yf5KjLjBkiZB+kaJ6BxEYxsmSY6BLNrwSDFHQ8SIvgah9WnXdi0lCIn0C/ qBVeSGSF3P6/p+f8uN6HBBdpQJiGByD5Tsi5O8GKLMWsI3kiMPAoXMC3uNpQt9IMXbYW QbMlBDCvKoZbXilnCmShXs2Vjrb111ESnG+5khnq59koceBNh5D00xAMWmff0nmEIOfs q3/UKDX/OYnpdoBm2dPCXG8TIOvhkplknyrZCy8g1GSHTCvo0+PN8Po8Sg/W+kA4WzBr FhKTBmBjH3jbhDJpNibvZmaTaxmySIB8h69aVaPHqjYPhFhs5NPQQHnPLGYOsNRhFXuJ ruSg==
MIME-Version: 1.0
X-Received: by 10.194.87.100 with SMTP id w4mr9318808wjz.48.1361630529181; Sat, 23 Feb 2013 06:42:09 -0800 (PST)
Received: by 10.194.11.71 with HTTP; Sat, 23 Feb 2013 06:42:09 -0800 (PST)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C733340EFE7@uxcn10-2.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C733340EFE7@uxcn10-2.UoA.auckland.ac.nz>
Date: Sat, 23 Feb 2013 09:42:09 -0500
Message-ID: 
From: Phillip Hallam-Baker 
To: Peter Gutmann 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF PKIX 
Subject: Re: [pkix] purpose of LDAP in PKI
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, 23 Feb 2013 14:42:11 -0000

Yuk!

An SMTP Message is not the right way to go here.

But why not add an SMTP transaction? It would be the logical way to
get keys for SMIME over SMTP. There would also need to be some
mechanism for managing keys between devices.


One of the big problems in the SMTP world is that there is no longer a
one to one mapping of clients to accounts. People read their mail on
multiple devices. Ergo end to end security simply does not work. At
the very least you need end to ends (plural) which means distributing
private keys across devices or you need end to service where the
emails are re-encrypted to get to the device.


On Wed, Feb 20, 2013 at 6:44 PM, Peter Gutmann
 wrote:
> Phillip Hallam-Baker  writes:
>
>>What was never finished was the one mechanism that a client can apply to
>>translate an SMTP email recipient address to the corresponding S/MIME
>>configuration (including cert).
>
> https://financialcryptography.com/mt/archives/000966.html
>
> (OK, so it'd need to be written up as an RFC).
>
> Peter.
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix



-- 
Website: http://hallambaker.com/

From pgut001@cs.auckland.ac.nz  Sun Feb 24 02:25:25 2013
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 B7F0F21F9001 for ; Sun, 24 Feb 2013 02:25:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163,  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 25-SmpCyU+oi for ; Sun, 24 Feb 2013 02:25:24 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 71A4A21F8FFA for ; Sun, 24 Feb 2013 02:25:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1361701525; x=1393237525; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=om2K3KR/0Uph2fyWf8sopoCY/ntGL4SpWCdtUlPYAsg=; b=m+aZd9M0kNqc26DhQ3omhTZRAcAG4O4ounsy7af7aRMlcEDzug1tUF2X 6dBnvtwUi0jVY+WwV508N8oJ+ok8SKSsNj8pupRudOrNOWVUCTY4MWDCy pFE/rqKO6oANpHYROqCee0WoSBzb/Dkdo3871BkNU5kXsY+GxtXywt37g w=;
X-IronPort-AV: E=Sophos;i="4.84,728,1355050800"; d="scan'208";a="171781789"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 24 Feb 2013 23:25:21 +1300
Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 24 Feb 2013 23:25:20 +1300
Received: from UXCN10-TDC02.UoA.auckland.ac.nz ([169.254.8.204]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Sun, 24 Feb 2013 23:25:20 +1300
From: Peter Gutmann 
To: IETF PKIX 
Thread-Topic: [pkix] purpose of LDAP in PKI
Thread-Index: Ac4SeT8tX3hH+lUUSMOwuxneaNV9fQ==
Date: Sun, 24 Feb 2013 10:25:20 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7333414744@uxcn10-tdc02.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] purpose of LDAP in PKI
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, 24 Feb 2013 10:25:25 -0000

Phillip Hallam-Baker  writes:=0A=
=0A=
>An SMTP Message is not the right way to go here. But why not add an SMTP=
=0A=
>transaction? It would be the logical way to get keys for SMIME over SMTP.=
=0A=
=0A=
What's the difference?  In this case you send a GETSMIME SMTP message and g=
et=0A=
back an SMTP message with the keys.  That's both "SMTP message" and "SMTP=
=0A=
transaction", I'm failing to see what the difference is.=0A=
=0A=
>One of the big problems in the SMTP world is that there is no longer a one=
 to=0A=
>one mapping of clients to accounts. People read their mail on multiple=0A=
>devices. Ergo end to end security simply does not work. At the very least =
you=0A=
>need end to ends (plural) which means distributing private keys across=0A=
>devices or you need end to service where the emails are re-encrypted to ge=
t=0A=
>to the device.=0A=
=0A=
Sure, the whole model is kinda broken.  OTOH GETSMIME fills a much-needed g=
ap,=0A=
replacing the "Uh, could you email me your keys, I don't have a copy"=0A=
mechanism that's currently in use.=0A=
=0A=
Peter.=

From mstjohns@comcast.net  Sun Feb 24 10:16:18 2013
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 57AD421F9087 for ; Sun, 24 Feb 2013 10:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.312
X-Spam-Level: 
X-Spam-Status: No, score=-100.312 tagged_above=-999 required=5 tests=[AWL=0.125, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpEEbryJgXVu for ; Sun, 24 Feb 2013 10:16:17 -0800 (PST)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 30CA721F8461 for ; Sun, 24 Feb 2013 10:16:17 -0800 (PST)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta10.westchester.pa.mail.comcast.net with comcast id 4JDx1l0010QuhwU5AJGG5z; Sun, 24 Feb 2013 18:16:16 +0000
Received: from Mike-T530.comcast.net ([68.83.212.126]) by omta02.westchester.pa.mail.comcast.net with comcast id 4JGE1l0182kB7pQ3NJGFbG; Sun, 24 Feb 2013 18:16:16 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 24 Feb 2013 13:16:15 -0500
To: Peter Gutmann ,IETF PKIX 
From: Michael StJohns 
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7333414744@uxcn10-tdc02.UoA. auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C7333414744@uxcn10-tdc02.UoA.auckland.ac.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361729776; bh=8x6F7i/8CLtF6CTTjZH6yhniq6osYB87mIdO00S0gis=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=axm7Yhe5QeyvG6FsVYPJLQ5pYyzeWdV0npItKWx9vjsx9HNVnzrSyhNHyv8/bxuvw l0hQm4Yj4JmptPs9gq1EfmZAnENYSYrgoKg8XCY+e5cAEBzYpWcQ28gGSvx7qMZ2Pd 5ftGlyOYCqp8c1e9vOohonRwVPv3PZna8/ulFCErm4UpED6KtLdFaO+gjDbuVs5wVr QJl1luG4GRKAsNvAsJ+/4WAllSVuRq0scNKHF5iMqJ7ZueAypLKSQ9+tpkQ59XBN4x dGX7yhNwtSrjPGKXn0NF9PIz+ZBt2l89x0unpLHVKi8zfU2eud/HbbtDvAxeh+JVg1 4MEH7YCiTzJQQ==
Message-Id: <20130224181617.30CA721F8461@ietfa.amsl.com>
Subject: Re: [pkix] purpose of LDAP in PKI
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, 24 Feb 2013 18:16:18 -0000

At 05:25 AM 2/24/2013, Peter Gutmann wrote:
>Phillip Hallam-Baker  writes:
>
>>An SMTP Message is not the right way to go here. But why not add an SMTP
>>transaction? It would be the logical way to get keys for SMIME over SMTP.
>
>What's the difference?  In this case you send a GETSMIME SMTP message and get
>back an SMTP message with the keys.  That's both "SMTP message" and "SMTP
>transaction", I'm failing to see what the difference is.
>
>>One of the big problems in the SMTP world is that there is no longer a one to
>>one mapping of clients to accounts. People read their mail on multiple
>>devices. Ergo end to end security simply does not work. At the very least you
>>need end to ends (plural) which means distributing private keys across
>>devices or you need end to service where the emails are re-encrypted to get
>>to the device.
>
>Sure, the whole model is kinda broken.  OTOH GETSMIME fills a much-needed gap,
>replacing the "Uh, could you email me your keys, I don't have a copy"
>mechanism that's currently in use.


Yup - and from the other end, "REGISTERSMIME" to store your cert with your local MTA/Message store so you don't have to be online for someone to get your cert.

But does that model work if you've got multiple MTAs between sender and receiver?  Does your local MTA translate the GETSMIME into a store and forward request of some sort?

Mike


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



From pgut001@cs.auckland.ac.nz  Sun Feb 24 16:14:06 2013
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 8132521F90D4 for ; Sun, 24 Feb 2013 16:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.441
X-Spam-Level: 
X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158,  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 ulJ+zFS7ZZ4w for ; Sun, 24 Feb 2013 16:14:05 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id EE7C621F90C4 for ; Sun, 24 Feb 2013 16:14:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1361751245; x=1393287245; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=/G/1DKW33K7TWNByFWPU+Cz68KKVLk2RyXd27NYOFQw=; b=coN5ZXUv1gumNFXo2Pa24QBNQtfVxvGSEz5PsZ2+Xf7D7tr27uO2R3eP T0CRGRydG630apboPmXYAwIQuTCykrr0XIZ8l47f2DYib/p1O84yHxN3I AKoZD4nVqXM/u9LG91vxScT6+obgWQ0DzTaQWEAYBBtFzC2SPYSTV3VNc M=;
X-IronPort-AV: E=Sophos;i="4.84,731,1355050800"; d="scan'208";a="171900093"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Feb 2013 13:14:00 +1300
Received: from UXCN10-TDC02.UoA.auckland.ac.nz ([169.254.8.204]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 13:14:00 +1300
From: Peter Gutmann 
To: IETF PKIX 
Thread-Topic: [pkix] purpose of LDAP in PKI
Thread-Index: Ac4S7QIbMtXuBqxmTRKwZeVMG44KTQ==
Date: Mon, 25 Feb 2013 00:13:59 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7333417A1A@uxcn10-tdc02.UoA.auckland.ac.nz>
Accept-Language: en-GB, en-NZ, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pkix] purpose of LDAP in PKI
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, 25 Feb 2013 00:14:06 -0000

Michael StJohns  writes:=0A=
=0A=
>But does that model work if you've got multiple MTAs between sender and=0A=
>receiver?  Does your local MTA translate the GETSMIME into a store and=0A=
>forward request of some sort?=0A=
=0A=
I think you're over-thinking this.  At the moment we have nothing at all.  =
In=0A=
addition, probably something like 99% of all email is protected through=0A=
STARTTLS, not S/MIME (or PGP, or anything else), simply because STARTTLS is=
=0A=
almost everywhere and S/MIME and PGP in comparison are almost nowhere (this=
 is=0A=
based on a survey of incoming/outgoing email at a couple of sites I did wit=
h a=0A=
few other folks a few years back).  So we're already only solving about 1% =
(or=0A=
less) of the problem no matter what we do.  If GETSMIME solves, say, 90% of=
=0A=
the 1%, that leaves 0.1% unsolved, and for something like that you can addr=
ess=0A=
it on a case-by-case basis.  You're not looking for a perfect, universal=0A=
solution, just a good-enough solution that solves a big chunk of the curren=
t=0A=
problem without being too much of a pain to deploy.=0A=
=0A=
Peter.=0A=

From James.H.Manger@team.telstra.com  Sun Feb 24 18:41:41 2013
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 0CA2C21F9191 for ; Sun, 24 Feb 2013 18:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
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 a77RHtE0fdVm for ; Sun, 24 Feb 2013 18:41:40 -0800 (PST)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5A521F9071 for ; Sun, 24 Feb 2013 18:41:37 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,730,1355058000"; d="scan'208";a="119854556"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 25 Feb 2013 13:41:33 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6996"; a="165801406"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcavi.tcif.telstra.com.au with ESMTP; 25 Feb 2013 13:41:33 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Mon, 25 Feb 2013 13:40:33 +1100
From: "Manger, James H" 
To: Stefan Santesson , "pkix@ietf.org" 
Date: Mon, 25 Feb 2013 13:40:31 +1100
Thread-Topic: [pkix] AuthContext Certificate extension
Thread-Index: Ac4QfS6LC/UTeiuoTZ+RTDnl9sVZFwCd1pJg
Message-ID: <255B9BB34FB7D647A506DC292726F6E1150A566201@WSMSG3153V.srv.dir.telstra.com>
References:  
In-Reply-To: 
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [pkix] AuthContext Certificate 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, 25 Feb 2013 02:41:41 -0000

U3RlZmFuLA0KDQpJIHNob3VsZG4ndCBjb21tZW50IG9uIGRyYWZ0LXNhbnRlc3Nvbi1hdXRoLWNv
bnRleHQtZXh0ZW5zaW9uIGFzIEkgaGF2ZSBubyBiYWNrZ3JvdW5kIGFzIHRvIHdoYXQgaXQgaXMg
YWxsIGFib3V0LCBidXQgSSBhbSBpbnRlcmVzdGVkIGluIGVuY29kaW5nIGNlcnRpZmljYXRlcy4N
Cg0KVGhlIEF1dGhlbnRpY2F0aW9uQ29udGV4dHMgY2VydGlmaWNhdGUgZXh0ZW5zaW9uIGhhcyBh
IHN0cmFuZ2UgbWl4IG9mIERFUiwgSlNPTiwgWE1MLCBhbmQgdGV4dC4gSXQgc2VlbXMgdG8gY29t
YmluZSBhbGwgdGhlIHdvcnN0IGV4YW1wbGVzIG9mIGhvdyB0byBlbWJlZCBzdHVmZiBpbiBBU04u
MSBpbnRvIG9uZSBmaWVsZC4NCg0KVGhlIGNvbnRleHRJbmZvIGZpZWxkIGlzIGRlZmluZWQgYW4g
YXMgT0NURVQgU1RSSU5HLiBXaGVuIHRoZSBvcHRpb25hbCBtaW1lVHlwZSBmaWVsZCBpcyBhYnNl
bnQgdGhlIE9DVEVUIFNUUklORyBob2xkcyBhIERFUi1lbmNvZGluZy4gVGhpcyBsb29rcyBsaWtl
IGV4dG5WYWx1ZSBPQ1RFVCBTVFJJTkcgaW4gYW4gRXh0ZW5zaW9uLiBQcmVzdW1hYmx5IHRoZSBj
b250ZXh0VHlwZSB2YWx1ZSBpcyBzdXBwb3NlZCB0byBpZGVudGlmeSB0aGUgQVNOLjEgdHlwZSBv
ZiB0aGUgZW1iZWRkZWQgdmFsdWUgKGxpa2UgZXh0bklkKS4gSG93ZXZlciB0aGlzIGlzbid0IGV4
cGxpY2l0bHkgc3RhdGVkOyB0aGVyZSBpcyBubyBjb3JyZXNwb25kaW5nIG9iamVjdCBjbGFzcyAo
ZXF1aXZhbGVudCB0byBFWFRFTlNJT04pOyB0aGVyZSBpcyBubyAiKENPTlRBSU5JTkcgLi4uIEVO
Q09ERUQgQlkgZGVyKSIgY29uc3RyYWludCBpbiB0aGUgQVNOLjEuDQoNCldoZW4gdGhlIG1pbWVU
eXBlIGZpZWxkIGlzIHByZXNlbnQsIGl0IGRlZmluZXMgdGhlIGZvcm1hdCBvZiB0aGUgY29udGV4
dEluZm8gdmFsdWUuIElmIHRoZSBmb3JtYXQgaXMgVVRGLTgtZW5jb2RlZCB0ZXh0LCB0aGUgVVRG
LTggYXBwZWFycyBkaXJlY3RseSBpbiB0aGUgY29udGV4dEluZm8gT0NURVQgU1RSSU5HLCBub3Qg
aW5zaWRlLCBzYXksIGEgVVRGOFN0cmluZy4NCg0KU28gY29udGV4dEluZm8gc29tZXRpbWVzIGhv
bGRzIGEgREVSLWVuY29kaW5nLCBhbmQgYXQgb3RoZXIgdGltZXMgaG9sZCByYXcgYnl0ZXMgb2Yg
c29tZSBvdGhlciBmb3JtYXQuIFBlcmhhcHMgYSBjbG9zZSBhbmFsb2d5IGlzIHRoZSBzdWJqZWN0
UHVibGljS2V5IEJJVCBTVFJJTkcgdGhhdCBzb21ldGltZXMgaG9sZHMgREVSIChlZyBTRVFVRU5D
RSBvZiBtb2R1bHVzIGFuZCBwdWJsaWMgZXhwb25lbnQgZm9yIGFuIFJTQSBrZXkpIGFuZCBzb21l
dGltZSByYXcgYnl0ZXMgKGVnIGZvciBhbiBlbGxpcHRpYyBjdXJ2ZSBwdWJsaWMga2V5KS4gc3Vi
amVjdFB1YmxpY0tleSBpcyBub3QgYSBnb29kIGV4YW1wbGUgdG8gcmVwZWF0Lg0KDQoNClRvIGlu
Y2x1ZGUgWE1MIHZhbHVlcyAoU0FNTCkgaW4gYW4gQVNOLjEgdmFsdWUgKENlcnRpZmljYXRlKSBh
IHRoaXJkIHN5bnRheCBpcyBpbnRyb2R1Y2VkOiBKU09OLiBEb2VzIGFuIGFwcCB1c2luZyB0aGUg
SlNPTiByZWFsbHkgbm90IG5lZWQgdG8gYWxzbyBwcm9jZXNzIHRoZSBBU04uMSBjZXJ0aWZpY2F0
ZSBmaWVsZHMgc28gaXQgY2FuIGdldCBhd2F5IHdpdGggb25seSB1bmRlcnN0YW5kaW5nICJlYXN5
IEpTT04iPw0KDQoNCmNlcnRSZWYgaXMgc3VwcG9zZWQgdG8gcmVmZXJlbmNlIGEgdmFsdWUgaW4g
dGhlIGNlcnQuIFdoZW4gYSB2YWx1ZSBpcyBpbiB0aGUgc3ViamVjdCBmaWVsZCBhbiBhdHRyaWJ1
dGUgdHlwZSBpcyBwcm92aWRlZCAoZWcgIjIuNS40LjUiIGZvciBzZXJpYWxOdW1iZXIpLiBIb3dl
dmVyLCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgc2VyaWFsTnVtYmVyIGF0dHJpYnV0ZXMgaW4gYSBE
TiAoZWcgc2VyaWFsTnVtYmVyIGhvbGRpbmcgYW4gb3JnIG51bWJlciwgdGhlbiBhIHNlcmlhbE51
bWJlciBpbiBhIGxvd2VyIFJETiBob2xkaW5nIGEgc3RhZmYgaWQpLg0KDQoNClRoZSBleGFtcGxl
IGZvciBhdXRoZW50aWNhdGlvbkluc3RhbnQgaXMgIkZlYiAxMiwgMjAxMyAxMjozNDo0NyBBTSIu
IFN1cmVseSB3ZSBzaG91bGQgdXNlIGEgYmV0dGVyIGRhdGUgZm9ybWF0IGZvciBuZXcgc3BlY3Mu
IEZvciBpbnN0YW5jZSwgIjIwMTMtMDItMTJUMDA6MzQ6NDdaIi4NCg0KDQptaW1lVHlwZSBpcyBh
IFByaW50YWJsZVN0cmluZy4gQ2FuJ3Qgd2UganVzdCB1c2UgVVRGOFN0cmluZyBmb3IgZXZlcnl0
aGluZyBuZXc/DQoNCg0KT2JqZWN0IGlkZW50aWZpZXIgYXJlIGVuY29kZWQgaW4gMyBkaWZmZXJl
bnQgd2F5cyBpcyB0aGlzIG9uZSBleHRlbnNpb246IERFUi1lbmNvZGluZyAoZWcgMDYgMDMgNTUw
NDA1KTsgZG90dGVkLWRlY2ltYWwgbm90YXRpb24gKGVnICIyLjUuNC41Iik7IGFuZCBhcyBhIFVS
SSAoZWcgInVybjpvaWQ6Mi41LjQuNSIpLiBQZXJoYXBzIHRoYXQgaXMgIm5lY2Vzc2FyeSIsIGJ1
dCBpdCBpcyB1bmZvcnR1bmF0ZS4NCg0KDQpUaGUgc3BlYyBzYXlzIGFwcGxpY2F0aW9ucyBNVVNU
IGlnbm9yZSBhbnkgYXV0aGVudGljYXRpb24gY29udGV4dCB0eXBlcyB0aGV5IGRvIG5vdCB1bmRl
cnN0YW5kLiBXaGF0IGlmIHRoZSBleHRlbnNpb24gaXMgbWFya2VkIGNyaXRpY2FsPyBTdXJlbHkg
eW91IE1VU1QgdW5kZXJzdGFuZCBhdCBsZWFzdCAxIEF1dGhlbnRpY2F0aW9uQ29udGV4dCBpbiB0
aGF0IGNhc2U/IA0KDQoNCldvdWxkbid0IHlvdSBiZSBiZXR0ZXIgb2ZmIHNwZWNpZnlpbmc6DQog
IHNhbWxBdXRoQ29udGV4dGluSlNPTiBFWFRFTlNJT04gOjo9IHsNCiAgICBTWU5UQVggVVRGOFN0
cmluZw0KICAgIElERU5USUZJRUQgQlkge2lzbygxKSBtZW1iZXItYm9keSgyKSBzZSg3NTIpIGUt
bGVnbmFtbmRlbigyMDEpIDUgMX0gfQ0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCj4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcGtpeC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86
cGtpeC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gU3RlZmFuIFNhbnRlc3Nvbg0K
PiBTZW50OiBGcmlkYXksIDIyIEZlYnJ1YXJ5IDIwMTMgODo0OCBBTQ0KPiBUbzogU3RlZmFuIFNh
bnRlc3NvbjsgcGtpeEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3BraXhdIEF1dGhDb250ZXh0
IENlcnRpZmljYXRlIGV4dGVuc2lvbg0KPiANCj4gSSBoYXZlIHVwZGF0ZWQgdGhpcyBkcmFmdCB3
aXRoIGEgZnVsbCBjZXJ0aWZpY2F0ZSBleGFtcGxlLiBBbmQgZml4ZWQNCj4gc29tZSBuaXRzLg0K
PiBJZiB0aW1lIHBlcm1pdHMgSSB3aWxsIG1ha2UgYSBzaG9ydCBwcmVzZW50YXRpb24gb2YgdGhp
cyBpbiBPcmxhbmRvLg0KPiANCj4gSSBoYXZlIHJlY2VpdmVkIHNvbWUgcHJpdmF0ZSByZXZpZXdz
LiBJJ20gcmVhbGx5IGdyYXRlZnVsIGZvciB0aGF0Lg0KPiBNb3JlIHRob3VnaHRzIGFuZCByZXZp
ZXdzIHdvdWxkIGJlIG11Y2ggYXBwcmVjaWF0ZWQuDQo+IA0KPiBUaGFua3MNCj4gDQo+IC9TdGVm
YW4NCj4gDQo+IA0KPiBPbiAyLzEzLzEzIDk6MDIgQU0sICJTdGVmYW4gU2FudGVzc29uIiA8c3Rl
ZmFuQGFhYS1zZWMuY29tPiB3cm90ZToNCj4gDQo+ID5JIHdhcyBtYWRlIGF3YXJlIHRoYXQgdGhl
IGRvY3VtZW50IGxpbmsgbm8gbG9uZ2VyIHdvcmtzOg0KPiA+DQo+ID5IZXJlIGlzIGEgbGluayB0
byB0aGUgbGF0ZXN0IGN1cnJlbnQgZHJhZnQ6DQo+ID5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1zYW50ZXNzb24tYXV0aC1jb250ZXh0LWV4dGVuc2lvbg0KPiA+DQo+ID4NCj4gPlRo
YW5rcyB0byBKaW0gZm9yIGNoZWNraW5nIG5pdHMgYW5kIHRoZSBBU04uMSBtb2R1bGVzIQ0KPiA+
DQo+ID4vU3RlZmFuDQo+ID4NCj4gPg0KPiA+DQo+ID5PbiAyLzEyLzEzIDE6MTUgUE0sICJTdGVm
YW4gU2FudGVzc29uIiA8c3RlZmFuQGFhYS1zZWMuY29tPiB3cm90ZToNCj4gPg0KPiA+PkkgaGF2
IHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBhcyBhbiBpbmRpdmlkdWFsIHN1Ym1pc3Npb246DQo+ID4+
DQo+ID4+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1zYW50ZXNzb24tYXV0aC1jb250ZXh0
LWV4dGVuc2lvbi0wMC50eHQNCj4gPj4NCj4gPj5BYnN0cmFjdA0KPiA+Pg0KPiA+PiAgIFRoaXMg
ZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRlbnNpb24gdG8gY2VydGlmaWNhdGVzIGFjY29yZGluZyB0
bw0KPiA+PiAgIFtSRkM1MjgwXS4gVGhlIGV4dGVuc2lvbiBkZWZpbmVkIGluIHRoaXMgZG9jdW1l
bnQgaG9sZHMgZGF0YSBhYm91dA0KPiA+PiAgIGhvdyB0aGUgY2VydGlmaWNhdGUgc3ViamVjdCB3
YXMgYXV0aGVudGljYXRlZCBieSB0aGUgQ2VydGlmaWNhdGlvbg0KPiA+PiAgIEF1dGhvcml0eSB3
aG8gaXNzdWVkIHRoZSBjZXJ0aWZpY2F0ZSB3aGVyZSB0aGlzIGV4dGVuc2lvbiBhcHBlYXJzLg0K
PiA+Pg0KPiA+PiAgIFRoaXMgZG9jdW1lbnQgYWxzbyBkZWZpbmVzIG9uZSBkYXRhIHN0cnVjdHVy
ZSBmb3IgaW5jbHVzaW9uIGluDQo+IHRoaXMNCj4gPj4gICBleHRlbnNpb24gdGhhdCBkZXNpZ25l
ZCB0byBob2xkIGluZm9ybWF0aW9uIHdoZW4gdGhlIHN1YmplY3QgaXMNCj4gPj4gICBhdXRoZW50
aWNhdGVkIHVzaW5nIGEgU0FNTCBhc3NlcnRpb24gW1NBTUxdLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0K
PiA+Pg0KPiA+PlRoaXMgZHJhZnQgZG9jdW1lbnRzIGFuIGV4dGVuc2lvbiB0aGF0IHdlIGhhdmUg
ZGVmaW5lZCBpbiB0aGUgU3dlZGlzaA0KPiA+Pm5hdGlvbmFsIGVsZWN0cm9uaWMgaWRlbnRpZmlj
YXRpb24gaW5mcmFzdHJ1Y3R1cmUgaW4gb3JkZXIgdG8gYmUgYWJsZQ0KPiA+PnRvIG1hdGNoIFNB
TUwgY3JlZGVudGlhbHMgd2l0aCBhc3NvY2lhdGVkIGVsZWN0cm9uaWMgc2lnbmF0dXJlcy4NCj4g
Pj5BbGwgc2lnbmF0dXJlIGNlcnRpZmljYXRlcyBhcmUgaXNzdWVkIGJ5IGEgY2VudHJhbCBzaWdu
YXR1cmUNCj4gPj5nZW5lcmF0aW9uIHNlcnZpY2Ugd2hpY2ggYXV0aGVudGljYXRlcyB0aGUgdXNl
ciB1c2luZyBTQU1MDQo+IGNyZWRlbnRpYWxzDQo+ID4+YW5kIHRoZW4gYWRkcyB0aGlzIGV4dGVu
c2lvbiB0byB0aGUgY2VydGlmaWNhdGUuDQo+ID4+DQo+ID4+VGhpcyBtYWtlcyBpdCBwb3NzaWJs
ZSBmb3Igc2VydmljZSBwcm92aWRlcnMgdG8gY29tcGFyZSB0aGUgc2lnbmVyIG9mDQo+ID4+YSBk
b2N1bWVudCB3aXRoIHRoZSBlbnRpdHkgY3VycmVudGx5IGxvZ2dlZCBpbnRvIHRoZSBzZXJ2aWNl
IHVzaW5nDQo+IFNBTUwuDQo+ID4+DQo+ID4+SSB3b3VsZCBoYXZlIGxvdmVkIGZvciB0aGlzIHRv
IGJlIHBhcnQgb2YgdGhlIFBLSVggcHJvY2VzcywgYnV0IGFzIHdlDQo+ID4+YXJlIG5vdCBhbGxv
d2VkIHRvIHRha2Ugb24gYW55IGZ1cnRoZXIgd29yaywgSSBsZXQgdGhpcyBkbyBhcyBhbg0KPiA+
PmluZGl2aWR1YWwgc3VibWlzc2lvbi4NCj4gPj4NCj4gPj5DdXJyZW50bHkgdGhlIGRyYWZ0IGlz
IGJhc2VkIG9uIHRoZSBTd2VkaXNoIGRlZmluZWQgT0lEcy4NCj4gPj4NCj4gPj5UaGVyZSBpcyBz
dGlsbCBhIHNob3J0IHdpbmRvdyBiZWZvcmUgd2UgbmVlZCB0byBsb2NrIHRoaXMNCj4gPj5zcGVj
aWZpY2F0aW9uIGluIHRoZSBTd2VkaXNoIHByb2plY3QsIGJ1dCBJJ20gdmVyeSBpbnRlcmVzdGVk
IGluDQo+ID4+cmV2aWV3IGZyb20gbWVtYmVycyBvZiB0aGlzIGdyb3VwLg0KPiA+PlRoZSBpbnRl
bnRpb24gaXMgY3VycmVudGx5IHRvIGdvIEluZm9ybWF0aW9uYWwsIGluIG9yZGVyIHRvIGp1c3QN
Cj4gPj5wcm92aWRlIGEgc3RhYmxlIHJlZmVyZW5jZSB0byB0aGlzIGV4dGVuc2lvbiBkZWZpbml0
aW9uLg0KPiA+PlNob3VsZCB0aGVyZSBiZSBhbiBpbnRlcmVzdCBpbiBtb3ZpbmcgdGhpcyB0byBz
dGFuZGFyZHMgdHJhY2ssIHRoZW4gSQ0KPiA+PndvdWxkIG5vdCBvYmplY3QgdG8gZG9pbmcgc28u
DQo+ID4+DQo+ID4+L1N0ZWZhbg0K

From internet-drafts@ietf.org  Sun Feb 24 23:14:48 2013
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 D4B6721F9211; Sun, 24 Feb 2013 23:14:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.469
X-Spam-Level: 
X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 EyX0BtT5HcGD; Sun, 24 Feb 2013 23:14:48 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21ED821F9212; Sun, 24 Feb 2013 23:14:48 -0800 (PST)
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.40
Message-ID: <20130225071448.2962.86006.idtracker@ietfa.amsl.com>
Date: Sun, 24 Feb 2013 23:14:48 -0800
Cc: pkix@ietf.org
Subject: [pkix] I-D Action: draft-ietf-pkix-est-05.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: Mon, 25 Feb 2013 07:14: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           : Enrollment over Secure Transport
	Author(s)       : Max Pritikin
                          Peter E. Yee
                          Dan Harkins
	Filename        : draft-ietf-pkix-est-05.txt
	Pages           : 53
	Date            : 2013-02-24

Abstract:
   This document profiles certificate enrollment for clients using
   Certificate Management over CMS (CMC) messages over a secure
   transport.  This profile, called Enrollment over Secure Transport
   (EST), describes a simple yet functional certificate management
   protocol targeting Public Key Infrastructure (PKI) clients that need
   to acquire client certificates and associated Certification Authority
   (CA) certificate(s).  It also supports client-generated public/
   private key pairs as well as key pairs generated by the CA.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pkix-est

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pkix-est-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-est-05


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


From tmiller@mitre.org  Mon Feb 25 05:59:18 2013
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 8EF6521F9317 for ; Mon, 25 Feb 2013 05:59:18 -0800 (PST)
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 CPvA4vM3bDxl for ; Mon, 25 Feb 2013 05:59:17 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0BC21F92BF for ; Mon, 25 Feb 2013 05:59:17 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 857C21F235D; Mon, 25 Feb 2013 08:59:16 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7913D1F2352; Mon, 25 Feb 2013 08:59:16 -0500 (EST)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.25]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 08:59:15 -0500
From: "Miller, Timothy J." 
To: Phillip Hallam-Baker , Peter Gutmann 
Thread-Topic: [pkix] purpose of LDAP in PKI
Thread-Index: Ac4PxC2Xu7mMns3GcUyrYt99kgo2XgCObB2AAFaN4AA=
Date: Mon, 25 Feb 2013 13:59:15 +0000
Message-ID: <195DB2510AAA004391F58E28FCE212000670BB9E@IMCMBX01.MITRE.ORG>
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [172.31.18.185]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF PKIX 
Subject: Re: [pkix] purpose of LDAP in PKI
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, 25 Feb 2013 13:59:18 -0000

On 2/23/13 8:42 AM, "Phillip Hallam-Baker"  wrote:

>One of the big problems in the SMTP world is that there is no longer a
>one to one mapping of clients to accounts. People read their mail on
>multiple devices.=20

I don't know about you, but IME reading email on multiple devices has
always been the case.  You have no idea how many helpdesk calls I fielded
at an ISP that started with "My email disappeared!"  (Think about late
90's POP3 services and you'll know why.)

By itself this doesn't mean end-to-end security is broken, it just means
users need private key portability and better public key discovery.  Well,
duh.  This isn't necessarily the fault of S/MIME; scoping the protocol as
it is makes sense *from a network engineer's perspective*.  No, it's not a
complete system (where are my -ilities?), but IETF doesn't build complete
systems.

But we should all know by now that S/MIME is the worst email security
protocol ever tried---except for all the others.  :)

-- T


From DPKemp@missi.ncsc.mil  Mon Feb 25 06:21:21 2013
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 1C96F21F932D for ; Mon, 25 Feb 2013 06:21:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300,  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 q9UejNoY5dxk for ; Mon, 25 Feb 2013 06:21:19 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0CA21F9300 for ; Mon, 25 Feb 2013 06:21:17 -0800 (PST)
Received: from clavin.missi.ncsc.mil (squid.missi.ncsc.mil [144.51.60.169]) by stingray.missi.ncsc.mil with ESMTP id r1PELGfT054816 for ; Mon, 25 Feb 2013 09:21:16 -0500 (EST)
Received: from clavin.missi.ncsc.mil ([169.254.1.166]) by SQUID.missi.ncsc.mil ([fe80::e032:d4c7:c51f:85ec%14]) with mapi id 14.02.0328.009; Mon, 25 Feb 2013 09:20:06 -0500
From: "Kemp, David P." 
To: IETF PKIX 
Thread-Topic: [pkix] purpose of LDAP in PKI
Thread-Index: Ac4S7QIb4gUx2YDeekahc4ab+LAdqgAdKiHw
Date: Mon, 25 Feb 2013 14:20:07 +0000
Message-ID: <5B1D7E570380A64989D4C069F7D14BC86DE1F424@clavin.missi.ncsc.mil>
References: <9A043F3CF02CD34C8E74AC1594475C7333417A1A@uxcn10-tdc02.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7333417A1A@uxcn10-tdc02.UoA.auckland.ac.nz>
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] purpose of LDAP in PKI
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, 25 Feb 2013 14:21:21 -0000

Perhaps the Microsoft TV commercials complaining that Google mines gmail fo=
r ad targeting (in a holier-than-thou plug for hotmail) will bring attentio=
n to the fact that STARTTLS does not protect email from server operators.

But if that causes enough angst among the Facebook generation to raise S/MI=
ME from 1% to 2%, I'd be shocked.  We care about privacy, as long as it's s=
omeone else's problem to solve without causing us any inconvenience.

Dave



-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Pet=
er Gutmann
Sent: Sunday, February 24, 2013 7:14 PM
To: IETF PKIX
Subject: Re: [pkix] purpose of LDAP in PKI

Michael StJohns  writes:

>But does that model work if you've got multiple MTAs between sender and=20
>receiver?  Does your local MTA translate the GETSMIME into a store and=20
>forward request of some sort?

I think you're over-thinking this.  At the moment we have nothing at all.  =
In addition, probably something like 99% of all email is protected through =
STARTTLS, not S/MIME (or PGP, or anything else), simply because STARTTLS is=
 almost everywhere and S/MIME and PGP in comparison are almost nowhere (thi=
s is based on a survey of incoming/outgoing email at a couple of sites I di=
d with a few other folks a few years back).  So we're already only solving =
about 1% (or
less) of the problem no matter what we do.  If GETSMIME solves, say, 90% of=
 the 1%, that leaves 0.1% unsolved, and for something like that you can add=
ress it on a case-by-case basis.  You're not looking for a perfect, univers=
al solution, just a good-enough solution that solves a big chunk of the cur=
rent problem without being too much of a pain to deploy.

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

From stefan@aaa-sec.com  Mon Feb 25 14:58:35 2013
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 D1EA121F91FC for ; Mon, 25 Feb 2013 14:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.551
X-Spam-Level: 
X-Spam-Status: No, score=-101.551 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 FFHV0uuYpz6O for ; Mon, 25 Feb 2013 14:58:34 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8FE21E80F6 for ; Mon, 25 Feb 2013 14:58:30 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 9A80349E2DC for ; Mon, 25 Feb 2013 23:58:27 +0100 (CET)
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 bf8ZK67LVeO3 for ; Mon, 25 Feb 2013 23:58:27 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E079549E2E1 for ; Mon, 25 Feb 2013 23:58:26 +0100 (CET)
Received: (qmail 29484 invoked from network); 25 Feb 2013 22:58:26 -0000
Received: from 81-236-19-140-no39.tbcn.telia.com (HELO [192.168.1.88]) (stefan@fiddler.nu@[81.236.19.140]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Feb 2013 22:58:26 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Mon, 25 Feb 2013 23:58:27 +0100
From: Stefan Santesson 
To: "Manger, James H" , "pkix@ietf.org" 
Message-ID: 
Thread-Topic: [pkix] AuthContext Certificate extension
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150A566201@WSMSG3153V.srv.dir.telstra.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] AuthContext Certificate 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, 25 Feb 2013 22:58:36 -0000

Hi James,

Thanks for the review.
Some comments below.

On 2/25/13 3:40 AM, "Manger, James H" 
wrote:

>Stefan,
>
>I shouldn't comment on draft-santesson-auth-context-extension as I have
>no background as to what it is all about, but I am interested in encoding
>certificates.
>
>The AuthenticationContexts certificate extension has a strange mix of
>DER, JSON, XML, and text. It seems to combine all the worst examples of
>how to embed stuff in ASN.1 into one field.

Worst in what sense? It works perfectly.

>
>The contextInfo field is defined an as OCTET STRING. When the optional
>mimeType field is absent the OCTET STRING holds a DER-encoding. This
>looks like extnValue OCTET STRING in an Extension. Presumably the
>contextType value is supposed to identify the ASN.1 type of the embedded
>value (like extnId). However this isn't explicitly stated; there is no
>corresponding object class (equivalent to EXTENSION); there is no
>"(CONTAINING ... ENCODED BY der)" constraint in the ASN.1.

The definition is perfectly clear. The mime type specifies the data format
and the OID defines what the actual content is.
>From the context of an ASN.1 parser, this is just bytes to be handed to an
upper application layer.


>
>When the mimeType field is present, it defines the format of the
>contextInfo value. If the format is UTF-8-encoded text, the UTF-8 appears
>directly in the contextInfo OCTET STRING, not inside, say, a UTF8String.

Bytes is the most generic format. Conversion from byte to other formats is
straightforward given that you know the data format given  by the MimeType.

>
>So contextInfo sometimes holds a DER-encoding, and at other times hold
>raw bytes of some other format. Perhaps a close analogy is the
>subjectPublicKey BIT STRING that sometimes holds DER (eg SEQUENCE of
>modulus and public exponent for an RSA key) and sometime raw bytes (eg
>for an elliptic curve public key). subjectPublicKey is not a good example
>to repeat.

Why not?
Its perfectly predictable and well defined, and provide exactly the degree
of flexibility that is desired.

>
>
>To include XML values (SAML) in an ASN.1 value (Certificate) a third
>syntax is introduced: JSON. Does an app using the JSON really not need to
>also process the ASN.1 certificate fields so it can get away with only
>understanding "easy JSON"?


Exactly. The application receiving the bytes does not need to understand
any ASN.1 at all.
Since the context of that application in the defined context info is
dealing with SAML assertions, ASN.1 is not a good data format.
You want to transform the data to data objects through a schema, something
that is hugely more supported through an XML schema or a defined JSON
structure.


>
>
>certRef is supposed to reference a value in the cert. When a value is in
>the subject field an attribute type is provided (eg "2.5.4.5" for
>serialNumber). However, there can be multiple serialNumber attributes in
>a DN (eg serialNumber holding an org number, then a serialNumber in a
>lower RDN holding a staff id).


It is assumed that you would not have multiple serial number attributes
holding exactly the same value.
But even if that would happen, the mapping still works. You get definitive
information about the source of the identity information.


>
>
>The example for authenticationInstant is "Feb 12, 2013 12:34:47 AM".
>Surely we should use a better date format for new specs. For instance,
>"2013-02-12T00:34:47Z".

This format is not defined by me. This is the JSON representation of a
date-time value.

>
>
>mimeType is a PrintableString. Can't we just use UTF8String for
>everything new?
>

Sure. But to my knowledge, mime type can always be expressed as printable
string. But I can change to IA5String.

>
>Object identifier are encoded in 3 different ways is this one extension:
>DER-encoding (eg 06 03 550405); dotted-decimal notation (eg "2.5.4.5");
>and as a URI (eg "urn:oid:2.5.4.5"). Perhaps that is "necessary", but it
>is unfortunate.

OK, Will look into that.

>
>
>The spec says applications MUST ignore any authentication context types
>they do not understand. What if the extension is marked critical? Surely
>you MUST understand at least 1 AuthenticationContext in that case?


If it is critical, you have to reject the cert. But I guess that could be
spelled out better.

>
>
>Wouldn't you be better off specifying:
>  samlAuthContextinJSON EXTENSION ::= {
>    SYNTAX UTF8String
>    IDENTIFIED BY {iso(1) member-body(2) se(752) e-legnamnden(201) 5 1} }


Do you mean in the ASN.1 section or the body. I have no strong opinion as
long as it works.

/Stefan


>
>--
>James Manger
>
>> -----Original Message-----
>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
>> Stefan Santesson
>> Sent: Friday, 22 February 2013 8:48 AM
>> To: Stefan Santesson; pkix@ietf.org
>> Subject: Re: [pkix] AuthContext Certificate extension
>> 
>> I have updated this draft with a full certificate example. And fixed
>> some nits.
>> If time permits I will make a short presentation of this in Orlando.
>> 
>> I have received some private reviews. I'm really grateful for that.
>> More thoughts and reviews would be much appreciated.
>> 
>> Thanks
>> 
>> /Stefan
>> 
>> 
>> On 2/13/13 9:02 AM, "Stefan Santesson"  wrote:
>> 
>> >I was made aware that the document link no longer works:
>> >
>> >Here is a link to the latest current draft:
>> >http://tools.ietf.org/html/draft-santesson-auth-context-extension
>> >
>> >
>> >Thanks to Jim for checking nits and the ASN.1 modules!
>> >
>> >/Stefan
>> >
>> >
>> >
>> >On 2/12/13 1:15 PM, "Stefan Santesson"  wrote:
>> >
>> >>I hav submitted a new draft as an individual submission:
>> >>
>> >>http://www.ietf.org/id/draft-santesson-auth-context-extension-00.txt
>> >>
>> >>Abstract
>> >>
>> >>   This document defines an extension to certificates according to
>> >>   [RFC5280]. The extension defined in this document holds data about
>> >>   how the certificate subject was authenticated by the Certification
>> >>   Authority who issued the certificate where this extension appears.
>> >>
>> >>   This document also defines one data structure for inclusion in
>> this
>> >>   extension that designed to hold information when the subject is
>> >>   authenticated using a SAML assertion [SAML].
>> >>
>> >>
>> >>
>> >>
>> >>This draft documents an extension that we have defined in the Swedish
>> >>national electronic identification infrastructure in order to be able
>> >>to match SAML credentials with associated electronic signatures.
>> >>All signature certificates are issued by a central signature
>> >>generation service which authenticates the user using SAML
>> credentials
>> >>and then adds this extension to the certificate.
>> >>
>> >>This makes it possible for service providers to compare the signer of
>> >>a document with the entity currently logged into the service using
>> SAML.
>> >>
>> >>I would have loved for this to be part of the PKIX process, but as we
>> >>are not allowed to take on any further work, I let this do as an
>> >>individual submission.
>> >>
>> >>Currently the draft is based on the Swedish defined OIDs.
>> >>
>> >>There is still a short window before we need to lock this
>> >>specification in the Swedish project, but I'm very interested in
>> >>review from members of this group.
>> >>The intention is currently to go Informational, in order to just
>> >>provide a stable reference to this extension definition.
>> >>Should there be an interest in moving this to standards track, then I
>> >>would not object to doing so.
>> >>
>> >>/Stefan



From James.H.Manger@team.telstra.com  Mon Feb 25 18:53:12 2013
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 EC01321E80D9 for ; Mon, 25 Feb 2013 18:53:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.601
X-Spam-Level: 
X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_47=0.6, RELAY_IS_203=0.994]
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 XGq5CnRxma0A for ; Mon, 25 Feb 2013 18:53:12 -0800 (PST)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8376421E80B3 for ; Mon, 25 Feb 2013 18:53:11 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,736,1355058000"; d="scan'208";a="120075542"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 26 Feb 2013 13:52:52 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6997"; a="114106706"
Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcdvi.tcif.telstra.com.au with ESMTP; 26 Feb 2013 13:52:52 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 26 Feb 2013 13:52:52 +1100
From: "Manger, James H" 
To: Stefan Santesson , "pkix@ietf.org" 
Date: Tue, 26 Feb 2013 13:52:50 +1100
Thread-Topic: [pkix] AuthContext Certificate extension
Thread-Index: Ac4Tq6Z7zHOf8qUbQ2mEmeZ/Up6d5QAFO+Hg
Message-ID: <255B9BB34FB7D647A506DC292726F6E1150AC3B0FD@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E1150A566201@WSMSG3153V.srv.dir.telstra.com> 
In-Reply-To: 
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [pkix] AuthContext Certificate 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: Tue, 26 Feb 2013 02:53:13 -0000

PiA+SSBzaG91bGRuJ3QgY29tbWVudCBvbiBkcmFmdC1zYW50ZXNzb24tYXV0aC1jb250ZXh0LWV4
dGVuc2lvbiBhcyBJDQo+IGhhdmUNCj4gPm5vIGJhY2tncm91bmQgYXMgdG8gd2hhdCBpdCBpcyBh
bGwgYWJvdXQsIGJ1dCBJIGFtIGludGVyZXN0ZWQgaW4NCj4gPmVuY29kaW5nIGNlcnRpZmljYXRl
cy4NCj4gPg0KPiA+VGhlIEF1dGhlbnRpY2F0aW9uQ29udGV4dHMgY2VydGlmaWNhdGUgZXh0ZW5z
aW9uIGhhcyBhIHN0cmFuZ2UgbWl4IG9mDQo+ID5ERVIsIEpTT04sIFhNTCwgYW5kIHRleHQuIEl0
IHNlZW1zIHRvIGNvbWJpbmUgYWxsIHRoZSB3b3JzdCBleGFtcGxlcw0KPiBvZg0KPiA+aG93IHRv
IGVtYmVkIHN0dWZmIGluIEFTTi4xIGludG8gb25lIGZpZWxkLg0KPiANCj4gV29yc3QgaW4gd2hh
dCBzZW5zZT8gSXQgd29ya3MgcGVyZmVjdGx5Lg0KDQpBU04uMSBoYXMgYSB3ZWxsLWRlZmluZWQg
YW5kIGV4dGVuc2l2ZWx5IHVzZWQgbWVjaGFuaXNtIGZvciAiaG9sZXMiIGluIHR5cGVzIHRoYXQg
Y2FuIGhvbGQgYXJiaXRyYXJ5IHZhbHVlcyBkZWZpbmVkIGxhdGVyLiBPcmlnaW5hbGx5IGl0IHVz
ZWQgdGhlICJBTlkiIG9yICJBTlkgREVGSU5FRCBCWSB4eHgiIG5vdGF0aW9uLCB0aG91Z2ggbm93
IHdlIHVzZSBJbmZvcm1hdGlvbiBPYmplY3QgY2xhc3NlcyB0byBiZXR0ZXIgaW5kaWNhdGUgd2hp
Y2ggZmllbGQgaWRlbnRpZmllcyB0aGUgdHlwZSBvZiB0aGUgdmFsdWUgaW4gdGhlIGhvbGUgKGFu
ZCBvdGhlciBkZXRhaWxzKS4NCg0KRW1iZWRkaW5nIHN0dWZmIGluIGFuIE9DVEVUIFNUUklORyBt
aWdodCB3b3JrLCBidXQgaXQgaXMgYW4gYWJ1c2Ugb2YgQVNOLjEuDQoNCg0KPiA+VGhlIGNvbnRl
eHRJbmZvIGZpZWxkIGlzIGRlZmluZWQgYW4gYXMgT0NURVQgU1RSSU5HLiBXaGVuIHRoZSBvcHRp
b25hbA0KPiA+bWltZVR5cGUgZmllbGQgaXMgYWJzZW50IHRoZSBPQ1RFVCBTVFJJTkcgaG9sZHMg
YSBERVItZW5jb2RpbmcuIFRoaXMNCj4gPmxvb2tzIGxpa2UgZXh0blZhbHVlIE9DVEVUIFNUUklO
RyBpbiBhbiBFeHRlbnNpb24uIFByZXN1bWFibHkgdGhlDQo+ID5jb250ZXh0VHlwZSB2YWx1ZSBp
cyBzdXBwb3NlZCB0byBpZGVudGlmeSB0aGUgQVNOLjEgdHlwZSBvZiB0aGUNCj4gPmVtYmVkZGVk
IHZhbHVlIChsaWtlIGV4dG5JZCkuIEhvd2V2ZXIgdGhpcyBpc24ndCBleHBsaWNpdGx5IHN0YXRl
ZDsNCj4gPnRoZXJlIGlzIG5vIGNvcnJlc3BvbmRpbmcgb2JqZWN0IGNsYXNzIChlcXVpdmFsZW50
IHRvIEVYVEVOU0lPTik7DQo+IHRoZXJlDQo+ID5pcyBubyAiKENPTlRBSU5JTkcgLi4uIEVOQ09E
RUQgQlkgZGVyKSIgY29uc3RyYWludCBpbiB0aGUgQVNOLjEuDQo+IA0KPiBUaGUgZGVmaW5pdGlv
biBpcyBwZXJmZWN0bHkgY2xlYXIuIFRoZSBtaW1lIHR5cGUgc3BlY2lmaWVzIHRoZSBkYXRhDQo+
IGZvcm1hdCBhbmQgdGhlIE9JRCBkZWZpbmVzIHdoYXQgdGhlIGFjdHVhbCBjb250ZW50IGlzLg0K
DQpJcyB0aGVyZSBhIGNsZWFyIGRpc3RpbmN0aW9uIGJldHdlZW4gImRhdGEgZm9ybWF0IiBhbmQg
ImFjdHVhbCBjb250ZW50Ij8gSSBkb24ndCB0aGluayBzby4NCg0KPiBGcm9tIHRoZSBjb250ZXh0
IG9mIGFuIEFTTi4xIHBhcnNlciwgdGhpcyBpcyBqdXN0IGJ5dGVzIHRvIGJlIGhhbmRlZCB0bw0K
PiBhbiB1cHBlciBhcHBsaWNhdGlvbiBsYXllci4NCg0KU28gdGhlIEFTTi4xIHBhcnNlciBzdGls
bCBoYXMgdG8ganVzdCBoYW5kIHRoZSBieXRlcyB0byBhbiB1cHBlciBhcHAgbGF5ZXIsIGV2ZW4g
d2hlbiB0aGUgYnl0ZXMgYXJlIGFuIGVuY29kZWQgQVNOLjEgdmFsdWUgdGhhdCB0aGUgdXBwZXIg
YXBwIGxheWVyIGhhcyB0byBpbW1lZGlhdGVseSBoYW5kIGJhY2sgdG8gdGhlIEFTTi4xIHBhcnNl
ci4NCg0KPiA+V2hlbiB0aGUgbWltZVR5cGUgZmllbGQgaXMgcHJlc2VudCwgaXQgZGVmaW5lcyB0
aGUgZm9ybWF0IG9mIHRoZQ0KPiA+Y29udGV4dEluZm8gdmFsdWUuIElmIHRoZSBmb3JtYXQgaXMg
VVRGLTgtZW5jb2RlZCB0ZXh0LCB0aGUgVVRGLTgNCj4gPmFwcGVhcnMgZGlyZWN0bHkgaW4gdGhl
IGNvbnRleHRJbmZvIE9DVEVUIFNUUklORywgbm90IGluc2lkZSwgc2F5LCBhDQo+IFVURjhTdHJp
bmcuDQo+IA0KPiBCeXRlcyBpcyB0aGUgbW9zdCBnZW5lcmljIGZvcm1hdC4gQ29udmVyc2lvbiBm
cm9tIGJ5dGUgdG8gb3RoZXIgZm9ybWF0cw0KPiBpcyBzdHJhaWdodGZvcndhcmQgZ2l2ZW4gdGhh
dCB5b3Uga25vdyB0aGUgZGF0YSBmb3JtYXQgZ2l2ZW4gIGJ5IHRoZQ0KPiBNaW1lVHlwZS4NCg0K
Qnl0ZXMgaXMgdG9vIGdlbmVyaWMuIFdoZW4geW91IGtub3cgeW91IHdhbnQgdG8gaW5zZXJ0IFVU
Ri04LWVuY29kZWQgdGV4dCAoYXMgeW91IGRvIGluIHRoaXMgZHJhZnQpIGl0IGlzIGJldHRlciB0
byB1c2UgVVRGOFN0cmluZy4NCg0KPiA+U28gY29udGV4dEluZm8gc29tZXRpbWVzIGhvbGRzIGEg
REVSLWVuY29kaW5nLCBhbmQgYXQgb3RoZXIgdGltZXMgaG9sZA0KPiA+cmF3IGJ5dGVzIG9mIHNv
bWUgb3RoZXIgZm9ybWF0LiBQZXJoYXBzIGEgY2xvc2UgYW5hbG9neSBpcyB0aGUNCj4gPnN1Ympl
Y3RQdWJsaWNLZXkgQklUIFNUUklORyB0aGF0IHNvbWV0aW1lcyBob2xkcyBERVIgKGVnIFNFUVVF
TkNFIG9mDQo+ID5tb2R1bHVzIGFuZCBwdWJsaWMgZXhwb25lbnQgZm9yIGFuIFJTQSBrZXkpIGFu
ZCBzb21ldGltZSByYXcgYnl0ZXMgKGVnDQo+ID5mb3IgYW4gZWxsaXB0aWMgY3VydmUgcHVibGlj
IGtleSkuIHN1YmplY3RQdWJsaWNLZXkgaXMgbm90IGEgZ29vZA0KPiA+ZXhhbXBsZSB0byByZXBl
YXQuDQo+IA0KPiBXaHkgbm90Pw0KPiBJdHMgcGVyZmVjdGx5IHByZWRpY3RhYmxlIGFuZCB3ZWxs
IGRlZmluZWQsIGFuZCBwcm92aWRlIGV4YWN0bHkgdGhlDQo+IGRlZ3JlZSBvZiBmbGV4aWJpbGl0
eSB0aGF0IGlzIGRlc2lyZWQuDQoNCkkgZG9uJ3Qga25vdyBob3cgbXVjaCBmbGV4aWJpbGl0eSBp
cyBzdWl0YWJsZSBpbiB0aGlzIHVzZSBjYXNlLiBUaGUgZmFjdCB0aGF0IHRoZSBkcmFmdCBkZWZp
bmVzIG9uZSBzcGVjaWFsaXNlZCB2YWx1ZSAoVVRGLTggSlNPTiB3aXRoIGEgc3BlY2lmaWMgU0FN
TC1yZWxhdGVkIHNjaGVtYSkgc3VnZ2VzdHMgdG8gbWUgdGhhdCBhIGNvbnRleHRJbmZvIE9DVEVU
IFNUUklORyBpcyB0aGUgd3JvbmcgcGxhY2UgZm9yIGZsZXhpYmlsaXR5Lg0KDQoNCj4gPmNlcnRS
ZWYgaXMgc3VwcG9zZWQgdG8gcmVmZXJlbmNlIGEgdmFsdWUgaW4gdGhlIGNlcnQuIFdoZW4gYSB2
YWx1ZSBpcw0KPiA+aW4gdGhlIHN1YmplY3QgZmllbGQgYW4gYXR0cmlidXRlIHR5cGUgaXMgcHJv
dmlkZWQgKGVnICIyLjUuNC41IiBmb3INCj4gPnNlcmlhbE51bWJlcikuIEhvd2V2ZXIsIHRoZXJl
IGNhbiBiZSBtdWx0aXBsZSBzZXJpYWxOdW1iZXIgYXR0cmlidXRlcw0KPiA+aW4gYSBETiAoZWcg
c2VyaWFsTnVtYmVyIGhvbGRpbmcgYW4gb3JnIG51bWJlciwgdGhlbiBhIHNlcmlhbE51bWJlciBp
bg0KPiA+YSBsb3dlciBSRE4gaG9sZGluZyBhIHN0YWZmIGlkKS4NCj4gDQo+IA0KPiBJdCBpcyBh
c3N1bWVkIHRoYXQgeW91IHdvdWxkIG5vdCBoYXZlIG11bHRpcGxlIHNlcmlhbCBudW1iZXIgYXR0
cmlidXRlcw0KPiBob2xkaW5nIGV4YWN0bHkgdGhlIHNhbWUgdmFsdWUuDQo+IEJ1dCBldmVuIGlm
IHRoYXQgd291bGQgaGFwcGVuLCB0aGUgbWFwcGluZyBzdGlsbCB3b3Jrcy4gWW91IGdldA0KPiBk
ZWZpbml0aXZlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBzb3VyY2Ugb2YgdGhlIGlkZW50aXR5IGlu
Zm9ybWF0aW9uLg0KDQpTaW5jZSB0aGUgSlNPTiBkdXBsaWNhdGVzIHRoZSB2YWx1ZXMgKGVnICJW
YWxmcmlkIExpbmRlbWFuIiBhcHBlYXJzIGluIHRoZSBjZXJ0IHN1YmplY3QgbmFtZSBhbmQgaW4g
dGhlIGF1dGguY29udGV4dCBleHRlbnNpb24pIHBlcmhhcHMgaXQgaXNuJ3Qgc3RyaWN0bHkgbmVj
ZXNzYXJ5IGZvciBjZXJ0TmFtZVR5cGUgJiBjZXJ0UmVmIHRvIGluZGljYXRlIGEgdW5pcXVlIHZh
bHVlIGluIHRoZSBjZXJ0Lg0KDQpUaGUgZmFjdCB0aGF0IHZhbHVlcyBzdWNoIGFzICJWYWxmcmlk
IExpbmRlbWFuIiBhcmUgZHVwbGljYXRlZCBpbiB0aGUgY2VydCBsb29rcyBsaWtlIGEgZmxhdyB3
aXRoIHRoaXMgZXh0ZW5zaW9uLg0KDQo+ID5UaGUgZXhhbXBsZSBmb3IgYXV0aGVudGljYXRpb25J
bnN0YW50IGlzICJGZWIgMTIsIDIwMTMgMTI6MzQ6NDcgQU0iLg0KPiA+U3VyZWx5IHdlIHNob3Vs
ZCB1c2UgYSBiZXR0ZXIgZGF0ZSBmb3JtYXQgZm9yIG5ldyBzcGVjcy4gRm9yIGluc3RhbmNlLA0K
PiA+IjIwMTMtMDItMTJUMDA6MzQ6NDdaIi4NCj4gDQo+IFRoaXMgZm9ybWF0IGlzIG5vdCBkZWZp
bmVkIGJ5IG1lLiBUaGlzIGlzIHRoZSBKU09OIHJlcHJlc2VudGF0aW9uIG9mIGENCj4gZGF0ZS10
aW1lIHZhbHVlLg0KDQpJIGRvbid0IHRoaW5rIHNvLg0KVGhlIGNsb3Nlc3QgSSBoYXZlIGZvdW5k
IGlzIEVDTUFTY3JpcHQgTGFuZ3VhZ2UgU3BlYyAoNS4xIGVkaXRpb24sIEp1bmUgMjAxMSk6DQox
NS45LjEuMTUgRGF0ZSBUaW1lIFN0cmluZyBGb3JtYXQNCkVDTUFTY3JpcHQgZGVmaW5lcyBhIHN0
cmluZyBpbnRlcmNoYW5nZSBmb3JtYXQgZm9yIGRhdGUtdGltZXMgYmFzZWQgdXBvbiBhIHNpbXBs
aWZpY2F0aW9uIG9mIHRoZSBJU08gODYwMSBFeHRlbmRlZCBGb3JtYXQuIFRoZSBmb3JtYXQgaXMg
YXMgZm9sbG93czogWVlZWS1NTS1ERFRISDptbTpzcy5zc3NaDQoNCg0KPiA+bWltZVR5cGUgaXMg
YSBQcmludGFibGVTdHJpbmcuIENhbid0IHdlIGp1c3QgdXNlIFVURjhTdHJpbmcgZm9yDQo+ID5l
dmVyeXRoaW5nIG5ldz8NCj4gPg0KPiANCj4gU3VyZS4gQnV0IHRvIG15IGtub3dsZWRnZSwgbWlt
ZSB0eXBlIGNhbiBhbHdheXMgYmUgZXhwcmVzc2VkIGFzDQo+IHByaW50YWJsZSBzdHJpbmcuIEJ1
dCBJIGNhbiBjaGFuZ2UgdG8gSUE1U3RyaW5nLg0KDQpQbGVhc2UgZG9uJ3Qgc3dhcCBhIDc0LWNo
YXJhY3RlciByZXN0cmljdGlvbiAoUHJpbnRhYmxlU3RyaW5nKSBmb3IgYSAxMjgtY2hhcmFjdGVy
IHJlc3RyaWN0aW9uIChJQTVTdHJpbmcpLiBTdXBwb3J0IFVuaWNvZGU7IGp1c3QgdXNlIFVURjhT
dHJpbmcuDQoNCj4gPldvdWxkbid0IHlvdSBiZSBiZXR0ZXIgb2ZmIHNwZWNpZnlpbmc6DQo+ID4g
IHNhbWxBdXRoQ29udGV4dGluSlNPTiBFWFRFTlNJT04gOjo9IHsNCj4gPiAgICBTWU5UQVggVVRG
OFN0cmluZw0KPiA+ICAgIElERU5USUZJRUQgQlkge2lzbygxKSBtZW1iZXItYm9keSgyKSBzZSg3
NTIpIGUtbGVnbmFtbmRlbigyMDEpIDUNCj4gMX0NCj4gPn0NCj4gDQo+IA0KPiBEbyB5b3UgbWVh
biBpbiB0aGUgQVNOLjEgc2VjdGlvbiBvciB0aGUgYm9keS4gSSBoYXZlIG5vIHN0cm9uZyBvcGlu
aW9uDQo+IGFzIGxvbmcgYXMgaXQgd29ya3MuDQoNCkkgbWVhbnQgcmVwbGFjaW5nIHRoZSBBdXRo
ZW50aWNhdGlvbkNvbnRleHRzIEFTTi4xIHR5cGUgd2l0aCBVVEY4U3RyaW5nIC0tIGRyb3BwaW5n
IHRoZSBmbGV4aWJpbGl0eSB0byBoYXZlIG11bHRpcGxlIGF1dGhlbnRpY2F0aW9uIGNvbnRleHRz
IHdpdGggbXVsdGlwbGUgbWltZSB0eXBlcyBhbmQgY29udGV4dFR5cGVzLiBJZiBhbm90aGVyIHR5
cGUgY29tZXMgYWxvbmcgaXQgY2FuIGdvIGluIGl0cyBvd24gZXh0ZW5zaW9uLg0KDQotLQ0KSmFt
ZXMgTWFuZ2VyDQo=

From stefan@aaa-sec.com  Tue Feb 26 00:59:15 2013
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 D3D2F21F88BE for ; Tue, 26 Feb 2013 00:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.677
X-Spam-Level: 
X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_47=0.6, 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 h-EwXZKAD6uD for ; Tue, 26 Feb 2013 00:59:15 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id ACA3421F86BC for ; Tue, 26 Feb 2013 00:59:13 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 2BFC44A3076 for ; Tue, 26 Feb 2013 09:59:12 +0100 (CET)
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 CoqnBEvB17MI for ; Tue, 26 Feb 2013 09:59:10 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0712A4A3269 for ; Tue, 26 Feb 2013 09:58:23 +0100 (CET)
Received: (qmail 66287 invoked from network); 26 Feb 2013 08:58:14 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.105]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Feb 2013 08:58:14 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Tue, 26 Feb 2013 09:58:18 +0100
From: Stefan Santesson 
To: "Manger, James H" , "pkix@ietf.org" 
Message-ID: 
Thread-Topic: [pkix] AuthContext Certificate extension
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150AC3B0FD@WSMSG3153V.srv.dir.telstra.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] AuthContext Certificate 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: Tue, 26 Feb 2013 08:59:15 -0000

James,

On 2/26/13 3:52 AM, "Manger, James H" 
wrote:

>> >I shouldn't comment on draft-santesson-auth-context-extension as I
>> have
>> >no background as to what it is all about, but I am interested in
>> >encoding certificates.
>> >
>> >The AuthenticationContexts certificate extension has a strange mix of
>> >DER, JSON, XML, and text. It seems to combine all the worst examples
>> of
>> >how to embed stuff in ASN.1 into one field.
>> 
>> Worst in what sense? It works perfectly.
>
>ASN.1 has a well-defined and extensively used mechanism for "holes" in
>types that can hold arbitrary values defined later. Originally it used
>the "ANY" or "ANY DEFINED BY xxx" notation, though now we use Information
>Object classes to better indicate which field identifies the type of the
>value in the hole (and other details).
>
>Embedding stuff in an OCTET STRING might work, but it is an abuse of
>ASN.1.

No it is not!

An OCTET STRING is a perfectly valid placeholder for byte data that is
just byte data in the context of the ASN.1 parser.
This byte data will in most cases have some structure that makes sense to
an application.

This is exactly what is being done here.


>
>
>> >The contextInfo field is defined an as OCTET STRING. When the optional
>> >mimeType field is absent the OCTET STRING holds a DER-encoding. This
>> >looks like extnValue OCTET STRING in an Extension. Presumably the
>> >contextType value is supposed to identify the ASN.1 type of the
>> >embedded value (like extnId). However this isn't explicitly stated;
>> >there is no corresponding object class (equivalent to EXTENSION);
>> there
>> >is no "(CONTAINING ... ENCODED BY der)" constraint in the ASN.1.
>> 
>> The definition is perfectly clear. The mime type specifies the data
>> format and the OID defines what the actual content is.
>
>Is there a clear distinction between "data format" and "actual content"?
>I don't think so.

Of course there are.
Parsing the ASN.1 gives you three data objects.

1) data bytes from the OCTET SCTRING
2) a mime type (String) that lets you know whether the data bytes contains
JSON, XML or DER encoded ASN.1
3) An OID that defines the structure of the data content. If the mime type
is XML it will identify an XML Schema through which you can parse the
data. If the mime type is JSON it will identify a JSON Schema, if it is
ASN.1 it will identify an ASN.1 structure.

The ability to identify ASN.1 data is just for completeness, but that
should really be seen as an exception. In the implementations I have in
mind, you either want XML or JSON.
The reason why ASN.1 is default is because I haven't found any mime type
for DER encoded data, thus I solved that by having that as default.


>
>> From the context of an ASN.1 parser, this is just bytes to be handed to
>> an upper application layer.
>
>So the ASN.1 parser still has to just hand the bytes to an upper app
>layer, even when the bytes are an encoded ASN.1 value that the upper app
>layer has to immediately hand back to the ASN.1 parser.

Exactly. If it causes too much confusion, I'd rather take away the option
to provide DER encoded data. I don't need that option personally.
Embedding ASN.1 is the exception. Embedding JSON or XML is the typical
scenario.

>
>> >When the mimeType field is present, it defines the format of the
>> >contextInfo value. If the format is UTF-8-encoded text, the UTF-8
>> >appears directly in the contextInfo OCTET STRING, not inside, say, a
>> UTF8String.
>> 
>> Bytes is the most generic format. Conversion from byte to other formats
>> is straightforward given that you know the data format given  by the
>> MimeType.
>
>Bytes is too generic. When you know you want to insert UTF-8-encoded text
>(as you do in this draft) it is better to use UTF8String.

Former versions of this spec did that, but then it is not possible to
allow DER encoded data.
Having a byte blob allows all types of data. The mime type and the OID
makes sure that you know how to parse that data.


>
>> >So contextInfo sometimes holds a DER-encoding, and at other times hold
>> >raw bytes of some other format. Perhaps a close analogy is the
>> >subjectPublicKey BIT STRING that sometimes holds DER (eg SEQUENCE of
>> >modulus and public exponent for an RSA key) and sometime raw bytes (eg
>> >for an elliptic curve public key). subjectPublicKey is not a good
>> >example to repeat.
>> 
>> Why not?
>> Its perfectly predictable and well defined, and provide exactly the
>> degree of flexibility that is desired.
>
>I don't know how much flexibility is suitable in this use case. The fact
>that the draft defines one specialised value (UTF-8 JSON with a specific
>SAML-related schema) suggests to me that a contextInfo OCTET STRING is
>the wrong place for flexibility.

The fact that I too don't know how much flexibility is needed is the
reason why it is this open.
To me this is not a problem.

It is actually really easy to parse this extension, extract the data, oid
and mime type and hand it to the upper layer.
If the mime type is recognised, an application can do certain things with
it without understanding the OID, such as displaying the JSON or XML in a
viewer. If the OID is understood, the data can be parsed with a schema and
used to map against the original authentication context, such as a SAML
login context.


>
>
>> >certRef is supposed to reference a value in the cert. When a value is
>> >in the subject field an attribute type is provided (eg "2.5.4.5" for
>> >serialNumber). However, there can be multiple serialNumber attributes
>> >in a DN (eg serialNumber holding an org number, then a serialNumber in
>> >a lower RDN holding a staff id).
>> 
>> 
>> It is assumed that you would not have multiple serial number attributes
>> holding exactly the same value.
>> But even if that would happen, the mapping still works. You get
>> definitive information about the source of the identity information.
>
>Since the JSON duplicates the values (eg "Valfrid Lindeman" appears in
>the cert subject name and in the auth.context extension) perhaps it isn't
>strictly necessary for certNameType & certRef to indicate a unique value
>in the cert.
>
>The fact that values such as "Valfrid Lindeman" are duplicated in the
>cert looks like a flaw with this extension.

It is not a flaw. This is how it is supposed to work.
You may, as you pointed out have multiple occurrences of the same RDN
attributes.
One of them may be from one SAML attribute source and the other from
another SAML attribute source.

But I would not object to make the attribute value optional in the JSON
schema. That would actually make sense.

>
>> >The example for authenticationInstant is "Feb 12, 2013 12:34:47 AM".
>> >Surely we should use a better date format for new specs. For instance,
>> >"2013-02-12T00:34:47Z".
>> 
>> This format is not defined by me. This is the JSON representation of a
>> date-time value.
>
>I don't think so.
>The closest I have found is ECMAScript Language Spec (5.1 edition, June
>2011):
>15.9.1.15 Date Time String Format
>ECMAScript defines a string interchange format for date-times based upon
>a simplification of the ISO 8601 Extended Format. The format is as
>follows: YYYY-MM-DDTHH:mm:ss.sssZ


You are absolutely correct. Thanks for putting me straight.
The date-time in the example happens to be the default serialization
format used by Gson (com.google.gson) that I use.
However Gson have an open interface for choosing date format for
serialization.

I have changed it to the format you suggest.
This needs to go into the spec.


>
>
>> >mimeType is a PrintableString. Can't we just use UTF8String for
>> >everything new?
>> >
>> 
>> Sure. But to my knowledge, mime type can always be expressed as
>> printable string. But I can change to IA5String.
>
>Please don't swap a 74-character restriction (PrintableString) for a
>128-character restriction (IA5String). Support Unicode; just use
>UTF8String.

Sorry, mistyped. No problem, I can use UTF8String.

>
>> >Wouldn't you be better off specifying:
>> >  samlAuthContextinJSON EXTENSION ::= {
>> >    SYNTAX UTF8String
>> >    IDENTIFIED BY {iso(1) member-body(2) se(752) e-legnamnden(201) 5
>> 1}
>> >}
>> 
>> 
>> Do you mean in the ASN.1 section or the body. I have no strong opinion
>> as long as it works.
>
>I meant replacing the AuthenticationContexts ASN.1 type with UTF8String
>-- dropping the flexibility to have multiple authentication contexts with
>multiple mime types and contextTypes. If another type comes along it can
>go in its own extension.

I really want to avoid defining a new extension if I find a reason to
provide other data.

The current model makes extension parsing generic. The extension parser
just extracts data, oid and mime type and makes it available to the upper
applications.
I can change data format without ever changing the cert extension
implementation. That is worth a lot to me.

I don't really see the problem you are trying to avoid.

The added flexibility really releaves the provided context info structure
from being perfect for all types of valid contexts and all possible needs.
If this one don't meet your need, you can define your own without having
to define a new extension or even touch your cert parsing code.

/Stefan

>
>--
>James Manger



From stefan@aaa-sec.com  Tue Feb 26 01:46:13 2013
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 97D9221F89E1 for ; Tue, 26 Feb 2013 01:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.975
X-Spam-Level: 
X-Spam-Status: No, score=-101.975 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 buutbPlN7zFW for ; Tue, 26 Feb 2013 01:46:13 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1824821F89DA for ; Tue, 26 Feb 2013 01:46:12 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 105064A3E08 for ; Tue, 26 Feb 2013 10:46:11 +0100 (CET)
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 cHWw0Qn2WfGv for ; Tue, 26 Feb 2013 10:46:08 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id B71154A3FEA for ; Tue, 26 Feb 2013 10:42:50 +0100 (CET)
Received: (qmail 61924 invoked from network); 26 Feb 2013 09:42:50 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.105]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Feb 2013 09:42:50 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Tue, 26 Feb 2013 10:42:54 +0100
From: Stefan Santesson 
To: George Michaelson 
Message-ID: 
Thread-Topic: [pkix] AuthContext Certificate extension
In-Reply-To: <39197327-4EEB-47EB-9B5F-3AB889835F25@algebras.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: pkix@ietf.org
Subject: Re: [pkix] AuthContext Certificate 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: Tue, 26 Feb 2013 09:46:13 -0000

I could live with a choice.

But I still think the solution in the draft is easier to code and parse,
since I in any case never do parse the content but pass the data to an
upper application.
So I can just forward the bytes, while this example requires a somewhat
more complex interface to the upper application. But doable.

/Stefan


On 2/26/13 10:07 AM, "George Michaelson"  wrote:

>
>ANY DEFINED BY...
>
>EXTERNAL...
>
>these both exist for a reason surely?
>
>we recently played with:
>
>EXTERNALTAKE2  ::=  [UNIVERSAL 8] IMPLICIT SEQUENCE
>   {
>    type         OBJECT IDENTIFIER OPTIONAL,
>    descriptor   UTF8String  OPTIONAL,
>    encoding     CHOICE {
>                  single-ASN1-type  [0] ANY,
>                  octet-aligned     [1] IMPLICIT OCTET STRING,
>                  arbitrary         [2] IMPLICIT BIT STRING
>                 }
>   }
>
>-G



From stefan@aaa-sec.com  Tue Feb 26 06:29:36 2013
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 1EF0521F8A7B for ; Tue, 26 Feb 2013 06:29:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.667
X-Spam-Level: 
X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 C9-92rdo7jin for ; Tue, 26 Feb 2013 06:29:35 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0F121F8A18 for ; Tue, 26 Feb 2013 06:29:34 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id F36634A7BD2 for ; Tue, 26 Feb 2013 15:29:31 +0100 (CET)
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 OCWFvZ9gMv8U for ; Tue, 26 Feb 2013 15:29:31 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id B242E4A7BCE for ; Tue, 26 Feb 2013 15:29:31 +0100 (CET)
Received: (qmail 61138 invoked from network); 26 Feb 2013 14:29:31 -0000
Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.210]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Feb 2013 14:29:31 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Tue, 26 Feb 2013 15:29:43 +0100
From: Stefan Santesson 
To: "Manger, James H" , "pkix@ietf.org" 
Message-ID: 
Thread-Topic: [pkix] AuthContext Certificate extension
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150AC3B0FD@WSMSG3153V.srv.dir.telstra.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] AuthContext Certificate 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: Tue, 26 Feb 2013 14:29:36 -0000

I've been looking into this date-time thing today and it is a mess uglier
than was aware of.

Nothing seems 100% consistent.

ECMA is based on ISO 8601, but not exactly.
Further the ECMA spec uses a ":" sign in the timezone expression (+01:00)
instead of what common tools uses and expects, which is more aligned with
RFC 822 (+0100).

The Java SimpleDateFormat class that is used to stringify date and time is
using RFC 822 time zone, which seems to be almost compatible with the
successor of RFC 822 (RFC 5322), except that RFC 5322 seems to require a
leading whitespace.

I'm actually thinking that it would be better to simply use an XML schema
for this to get rid of this problem, since XML has a defined way of
expressing date.
That would also remove dependency on the JSON Schema draft.

/Stefan


On 2/26/13 3:52 AM, "Manger, James H" 
wrote:

>I don't think so.
>The closest I have found is ECMAScript Language Spec (5.1 edition, June
>2011):
>15.9.1.15 Date Time String Format
>ECMAScript defines a string interchange format for date-times based upon
>a simplification of the ISO 8601 Extended Format. The format is as
>follows: YYYY-MM-DDTHH:mm:ss.sssZ



From stefan@aaa-sec.com  Tue Feb 26 15:22:44 2013
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 7C25A21F8617 for ; Tue, 26 Feb 2013 15:22:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.411
X-Spam-Level: 
X-Spam-Status: No, score=-101.411 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_47=0.6, 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 s8hWpdELF45k for ; Tue, 26 Feb 2013 15:22:43 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5282021F862A for ; Tue, 26 Feb 2013 15:22:42 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id E8A884AD6CE for ; Wed, 27 Feb 2013 00:20:41 +0100 (CET)
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 aGZtzuWIsjd4 for ; Wed, 27 Feb 2013 00:20:41 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 5D5F64AD6CD for ; Wed, 27 Feb 2013 00:20:41 +0100 (CET)
Received: (qmail 30627 invoked from network); 26 Feb 2013 23:20:40 -0000
Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.211]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Feb 2013 23:20:40 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Wed, 27 Feb 2013 00:20:42 +0100
From: Stefan Santesson 
To: "Manger, James H" , "pkix@ietf.org" 
Message-ID: 
Thread-Topic: [pkix] AuthContext Certificate extension
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150AC3B0FD@WSMSG3153V.srv.dir.telstra.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] AuthContext Certificate 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: Tue, 26 Feb 2013 23:22:44 -0000

James,

After going through the date thing, I concluded that the document would be
better defined and distinct using an XML Schema instead of JSON.
I therefore decided to agree with you and to simplify the extension.

I actually think the ability to define what XML Schema that is used is
enough and I really don't need the option of going JSON or ASN.1 for this.

I have updated the draft but missed the cut-off by 40 minutes.

The new draft is available here in the mean while:
http://aaa-sec.com/_temp/draft-santesson-auth-context-extension-04.txt

/Stefan



On 2/26/13 3:52 AM, "Manger, James H" 
wrote:

>> >I shouldn't comment on draft-santesson-auth-context-extension as I
>> have
>> >no background as to what it is all about, but I am interested in
>> >encoding certificates.
>> >
>> >The AuthenticationContexts certificate extension has a strange mix of
>> >DER, JSON, XML, and text. It seems to combine all the worst examples
>> of
>> >how to embed stuff in ASN.1 into one field.
>> 
>> Worst in what sense? It works perfectly.
>
>ASN.1 has a well-defined and extensively used mechanism for "holes" in
>types that can hold arbitrary values defined later. Originally it used
>the "ANY" or "ANY DEFINED BY xxx" notation, though now we use Information
>Object classes to better indicate which field identifies the type of the
>value in the hole (and other details).
>
>Embedding stuff in an OCTET STRING might work, but it is an abuse of
>ASN.1.
>
>
>> >The contextInfo field is defined an as OCTET STRING. When the optional
>> >mimeType field is absent the OCTET STRING holds a DER-encoding. This
>> >looks like extnValue OCTET STRING in an Extension. Presumably the
>> >contextType value is supposed to identify the ASN.1 type of the
>> >embedded value (like extnId). However this isn't explicitly stated;
>> >there is no corresponding object class (equivalent to EXTENSION);
>> there
>> >is no "(CONTAINING ... ENCODED BY der)" constraint in the ASN.1.
>> 
>> The definition is perfectly clear. The mime type specifies the data
>> format and the OID defines what the actual content is.
>
>Is there a clear distinction between "data format" and "actual content"?
>I don't think so.
>
>> From the context of an ASN.1 parser, this is just bytes to be handed to
>> an upper application layer.
>
>So the ASN.1 parser still has to just hand the bytes to an upper app
>layer, even when the bytes are an encoded ASN.1 value that the upper app
>layer has to immediately hand back to the ASN.1 parser.
>
>> >When the mimeType field is present, it defines the format of the
>> >contextInfo value. If the format is UTF-8-encoded text, the UTF-8
>> >appears directly in the contextInfo OCTET STRING, not inside, say, a
>> UTF8String.
>> 
>> Bytes is the most generic format. Conversion from byte to other formats
>> is straightforward given that you know the data format given  by the
>> MimeType.
>
>Bytes is too generic. When you know you want to insert UTF-8-encoded text
>(as you do in this draft) it is better to use UTF8String.
>
>> >So contextInfo sometimes holds a DER-encoding, and at other times hold
>> >raw bytes of some other format. Perhaps a close analogy is the
>> >subjectPublicKey BIT STRING that sometimes holds DER (eg SEQUENCE of
>> >modulus and public exponent for an RSA key) and sometime raw bytes (eg
>> >for an elliptic curve public key). subjectPublicKey is not a good
>> >example to repeat.
>> 
>> Why not?
>> Its perfectly predictable and well defined, and provide exactly the
>> degree of flexibility that is desired.
>
>I don't know how much flexibility is suitable in this use case. The fact
>that the draft defines one specialised value (UTF-8 JSON with a specific
>SAML-related schema) suggests to me that a contextInfo OCTET STRING is
>the wrong place for flexibility.
>
>
>> >certRef is supposed to reference a value in the cert. When a value is
>> >in the subject field an attribute type is provided (eg "2.5.4.5" for
>> >serialNumber). However, there can be multiple serialNumber attributes
>> >in a DN (eg serialNumber holding an org number, then a serialNumber in
>> >a lower RDN holding a staff id).
>> 
>> 
>> It is assumed that you would not have multiple serial number attributes
>> holding exactly the same value.
>> But even if that would happen, the mapping still works. You get
>> definitive information about the source of the identity information.
>
>Since the JSON duplicates the values (eg "Valfrid Lindeman" appears in
>the cert subject name and in the auth.context extension) perhaps it isn't
>strictly necessary for certNameType & certRef to indicate a unique value
>in the cert.
>
>The fact that values such as "Valfrid Lindeman" are duplicated in the
>cert looks like a flaw with this extension.
>
>> >The example for authenticationInstant is "Feb 12, 2013 12:34:47 AM".
>> >Surely we should use a better date format for new specs. For instance,
>> >"2013-02-12T00:34:47Z".
>> 
>> This format is not defined by me. This is the JSON representation of a
>> date-time value.
>
>I don't think so.
>The closest I have found is ECMAScript Language Spec (5.1 edition, June
>2011):
>15.9.1.15 Date Time String Format
>ECMAScript defines a string interchange format for date-times based upon
>a simplification of the ISO 8601 Extended Format. The format is as
>follows: YYYY-MM-DDTHH:mm:ss.sssZ
>
>
>> >mimeType is a PrintableString. Can't we just use UTF8String for
>> >everything new?
>> >
>> 
>> Sure. But to my knowledge, mime type can always be expressed as
>> printable string. But I can change to IA5String.
>
>Please don't swap a 74-character restriction (PrintableString) for a
>128-character restriction (IA5String). Support Unicode; just use
>UTF8String.
>
>> >Wouldn't you be better off specifying:
>> >  samlAuthContextinJSON EXTENSION ::= {
>> >    SYNTAX UTF8String
>> >    IDENTIFIED BY {iso(1) member-body(2) se(752) e-legnamnden(201) 5
>> 1}
>> >}
>> 
>> 
>> Do you mean in the ASN.1 section or the body. I have no strong opinion
>> as long as it works.
>
>I meant replacing the AuthenticationContexts ASN.1 type with UTF8String
>-- dropping the flexibility to have multiple authentication contexts with
>multiple mime types and contextTypes. If another type comes along it can
>go in its own extension.
>
>--
>James Manger



From kent@bbn.com  Tue Feb 26 21:53:36 2013
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 4913A21F8522 for ; Tue, 26 Feb 2013 21:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.584
X-Spam-Level: 
X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 6XkMfZtE72OD for ; Tue, 26 Feb 2013 21:53:35 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CE22821F8526 for ; Tue, 26 Feb 2013 21:53:34 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:43593 helo=176.151.dhcp.conference.apricot.net) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UAZxM-000Dha-JO; Wed, 27 Feb 2013 00:53:33 -0500
Message-ID: <512D9F5A.7010103@bbn.com>
Date: Wed, 27 Feb 2013 00:53:30 -0500
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: pkix@ietf.org, ynir@checkpoint.com
References: <9A043F3CF02CD34C8E74AC1594475C733340E7BB@uxcn10-2.UoA.auckland.ac.nz> <5124E2AB.5020400@bull.net> 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
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, 27 Feb 2013 05:53:36 -0000

Yoav,

Your characterization of roles for SDOs does not constitute a partition. 
There are other options.

WGs in the IETF, when we do our work well, develop good, technical 
solutions for problems,
and communicate these solutions in a clear fashion, via RFCs.

Developers may or may not follow the RFCs we produce, either by accident 
or intentionally.
Thus implementations may differ because of ambiguities in the RFCs, 
because of implementation
sloppiness, or for business reasons (which may be good reasons, or not).

If an influential vendor elects to not follow some aspect of a standard, 
other vendors may feel
that they have to accommodate the deviation adopted by the influential 
vendor, to preserve interoperability.
The deviation from a standard may have obvious, adverse security 
implications, or subtle security
problems, or may just be a security-neutral alternative.

A WG can elect to modify a standard, to accommodate what has become 
common practice, or not.
If the WG modifies the RFC, and if the modification has adverse security 
implications, this
is bad. Even if the deviation from the standard is security-neutral, the 
change sets a bad
precedent, as it undermines the standards development process in which 
others invested time
and effort.

 From my perspective, making a change to a standard to accommodate 
deviations from the standard,
when the change does not address a bug in the standard, rewards bad 
behavior, and it cheapens RFCs.
I oppose such behavior in any IETF WG.

Steve

From stefan@aaa-sec.com  Wed Feb 27 02:42:01 2013
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 CB78B21F852B for ; Wed, 27 Feb 2013 02:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.728
X-Spam-Level: 
X-Spam-Status: No, score=-101.728 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 wh3aYx3YS4Mf for ; Wed, 27 Feb 2013 02:42:00 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECD121F8528 for ; Wed, 27 Feb 2013 02:41:59 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 8D27943D840 for ; Wed, 27 Feb 2013 11:41:57 +0100 (CET)
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 3MJ5hNpVUDBB for ; Wed, 27 Feb 2013 11:41:57 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 25E1143D8A5 for ; Wed, 27 Feb 2013 11:41:57 +0100 (CET)
Received: (qmail 10193 invoked from network); 27 Feb 2013 10:41:56 -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 ; 27 Feb 2013 10:41:56 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Wed, 27 Feb 2013 11:41:55 +0100
From: Stefan Santesson 
To: "Manger, James H" , "pkix@ietf.org" 
Message-ID: 
Thread-Topic: [pkix] AuthContext Certificate extension - XML
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] AuthContext Certificate extension - XML
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, 27 Feb 2013 10:42:01 -0000

After discussion with James below I made contextInfo optional and fixed
some minor issues.
Until ID submission starts again, the draft is available here:

http://aaa-sec.com/_temp/draft-santesson-auth-context-extension-04.txt

Diff from published draft 03:
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-santesso
n-auth-context-extension-03.txt&url2=http://aaa-sec.com/_temp/draft-santess
on-auth-context-extension-04.txt

/Stefan

On 2/27/13 10:17 AM, "Stefan Santesson"  wrote:

>James,
>
>After writing this and tanking a car ride to think about it, it strikes
>me 
>as obvious that this should be done exactly as SAML handles LoA
>declarations.
>
>The contextType URI (defining an XML Schema ns) is mandatory.
>The XML defined by the XML Schema is optional.
>
>The mapping rules may be implicit from the contextType URI, in which case
>it may be sufficient just just include the URI.
>
>SAML does this with LoA (AuthnContextClassRef) which is both an
>identifier 
>of an explicit ruleset and an XML Schema ns for expressing details about
>the rules.
>It is very common to just include just the URI and not the XML derived
>from the identified schema as your LoA declaration.
>
>This extension could be used the same way.
>
>/Stefan
>
>
>
>
>On 2/27/13 9:16 AM, "Stefan Santesson"  wrote:
>
>>Technically you are correct
>>
>>But, there is a clear point of convenience in having the Schema
>>identifier 
>>externally available.
>>
>>Normally you know what schema you expect some XML to follow before you
>>attempt to parse it.
>>That way you can parse it right into e.g. the compiled Java classes that
>>are derived from the schema.
>>
>>If I don't know the schema, I first have to parse the bytes/characters
>>into a neutral XML document and inspect it for name space declarations.
>>
>>The nearest example I can think of is how SAML assertion provides Level
>>of 
>>Assurance (LoA) information.
>>LoA is identified by a URI that also is an XML schema name space
>>identifier for specific LoA information.
>>
>>A SAML assertion may provide just the URI, or the URI and XML according
>>to 
>>the LoA schema.
>>Having the name space URI available outside of the XML makes it so much
>>easier and clean to parse the XML using the correct Schema in one pass.
>>
>>/Stefan
>>
>>
>>
>>On 2/27/13 1:21 AM, "Manger, James H" 
>>wrote:
>>
>>>Stefan,
>>>
>>>I'm not sure the XML namespace/schema stuff is quite right.
>>>
>>>You use http://id.elegnamnden.se/auth-cont/1.0/saci as: an XML
>>>namespace 
>>>id; imply it is an XML Schema id (or locator); and to identify the type
>>>of authentication context information.
>>>
>>>I doubt you need the contextType field. Shouldn't you just look at the
>>>XML (contextInfo) to see the namespace of the root element (and other
>>>elements), and/or any schemaLocation URIs that are declared? For
>>>example:
>>>
>>>>>      xmlns="http://id.elegnamnden.se/auth-cont/1.0/saci"
>>>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>      
>>>xsi:schemaLocation="http://id.elegnamnden.se/auth-cont/1.0/saci.xsd">
>>>...
>>>
>>>--
>>>James Manger
>>>
>>>
>>>> -----Original Message-----
>>>> From: Stefan Santesson [mailto:stefan@aaa-sec.com]
>>>> Sent: Wednesday, 27 February 2013 10:21 AM
>>>> To: Manger, James H; pkix@ietf.org
>>>> Subject: Re: [pkix] AuthContext Certificate extension
>>>> 
>>>> James,
>>>> 
>>>> After going through the date thing, I concluded that the document
>>>>would
>>>> be better defined and distinct using an XML Schema instead of JSON.
>>>> I therefore decided to agree with you and to simplify the extension.
>>>> 
>>>> I actually think the ability to define what XML Schema that is used is
>>>> enough and I really don't need the option of going JSON or ASN.1 for
>>>> this.
>>>> 
>>>> I have updated the draft but missed the cut-off by 40 minutes.
>>>> 
>>>> The new draft is available here in the mean while:
>>>> http://aaa-sec.com/_temp/draft-santesson-auth-context-extension-04.txt
>>>> 
>>>> /Stefan



From stefan@aaa-sec.com  Wed Feb 27 03:22:16 2013
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 3C30221F8528 for ; Wed, 27 Feb 2013 03:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.763
X-Spam-Level: 
X-Spam-Status: No, score=-101.763 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 1A0SMnccBitn for ; Wed, 27 Feb 2013 03:22:14 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 15ED321F84CA for ; Wed, 27 Feb 2013 03:22:11 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id A46E14B2DCD for ; Wed, 27 Feb 2013 12:22:10 +0100 (CET)
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 hWtFKA9xMSWo for ; Wed, 27 Feb 2013 12:22:10 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 469E64B2DA6 for ; Wed, 27 Feb 2013 12:22:10 +0100 (CET)
Received: (qmail 92101 invoked from network); 27 Feb 2013 11:22:09 -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 ; 27 Feb 2013 11:22:09 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Wed, 27 Feb 2013 12:22:09 +0100
From: Stefan Santesson 
To: Sean Turner , 
Message-ID: 
Thread-Topic: [pkix] AD review of draft-ietf-pkix-rfc2560bis
In-Reply-To: <5127A310.3000606@ieca.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [pkix] AD review of draft-ietf-pkix-rfc2560bis
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, 27 Feb 2013 11:22:16 -0000

Sean,

Comments in line

On 2/22/13 5:55 PM, "Sean Turner"  wrote:

>Two things I think we should discuss and a couple of comments:
>
>Discuss 1) s4.3: I totally agree with upgrading RSA with SHA-256 to a
>SHALL, but why are we updating RSA with SHA-1 to a SHALL?  With the
>known weaknesses, I could see leaving it at SHOULD.

This document includes the updates provided in RFC 6277 (Online
Certificate Status Protocol Algorithm Agility) of June 2011.
The rules you cite was the WG conclusion of that time.

I think it is wise from an interop perspective to require that compliant
clients must be able to "process" RSA with SHA-1 (which is the requirement
in 4.3).
That does not mean that an clients have to accept SHA-1 signed responses.
They just need to have the capability.


>
>Discuss 2) s4.3: The MTI algs section made me think that we need to say
>something about the key size as well.  Since we just had the same
>discussion about S/MIME not too long ago I suggest taking some text from
>RFC5751 s4.2/s4.3.

I'm not convinced. As I see it, this section deals with interop and not
security requirements for clients. For interop purposes it is normally
sufficient to say RSA.
Section 4.4.7 deals with the client's ability to specify it's Algorithmic
and public Key requirements using SMIMECapability and AlgorithmIdentifier.

You know that I hate hardcoding algorithm level requirements into protocol
specs, and this discussion proves the point.

We came to some conclusion in 6277 which was published less than 2 years
ago.
How long do you think it will take before any opinions on suitable
algorithms expressed here is outdated?

I would really like to see IETF doing a BCP on suitable algorithms that a
document like this could refer to that would allow the BCP to be a living
document.
So much pain of this kind could be avoided.


>
>c1) In s1, it looks like a header is missing for section 1.1 or "1.1"
>should be removed from the following:
>
>1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Fixed in a preliminary draft 14.

>
>c2) s2.6: r/Se further/See further

Fixed in a preliminary draft 14.


>
>c3) s4.4.7.1: In the last paragraph r/4.4.7.1/4.4.7.2 otherwise it's a
>circular reference ;)

Fixed in a preliminary draft 14.


>
>c4) s4.4.7.2.1: Is it clearer to say the responder should pick the
>highest precedence or the lowest numbered selection?  Just looking for
>consistency between the paragraph before the list and the one after the
>list.

I know that this particular text was crafted after some discussion as
result of an IESG discusses when publishing 6277.
Therefore I'm a bit reluctant to change it unless I have an agreed
replacement text.

I think personally that it is clear as it is.

A preliminary draft 14 is available here:
http://aaa-sec.com/_temp/rfc2560bis-14_01.txt

Diff:
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-pki
x-rfc2560bis-13.txt&url2=http://aaa-sec.com/_temp/rfc2560bis-14_01.txt

/Stefan


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



From turners@ieca.com  Wed Feb 27 06:07:07 2013
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 DA82F21F861C for ; Wed, 27 Feb 2013 06:07:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.017
X-Spam-Level: 
X-Spam-Status: No, score=-102.017 tagged_above=-999 required=5 tests=[AWL=0.248, 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 vPl3YAvp2JVR for ; Wed, 27 Feb 2013 06:07:05 -0800 (PST)
Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [67.18.36.20]) by ietfa.amsl.com (Postfix) with ESMTP id AF84221F859B for ; Wed, 27 Feb 2013 06:07:05 -0800 (PST)
Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id B1B687823C747; Wed, 27 Feb 2013 08:07:01 -0600 (CST)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 970FD7823C6A9 for ; Wed, 27 Feb 2013 08:07:01 -0600 (CST)
Received: from [108.45.16.214] (port=63040 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UAhey-0002yJ-1c; Wed, 27 Feb 2013 08:07:04 -0600
Message-ID: <512E1307.5080901@ieca.com>
Date: Wed, 27 Feb 2013 09:07:03 -0500
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
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
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.45.16.214]:63040
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: pkix@ietf.org
Subject: Re: [pkix] AD review of draft-ietf-pkix-rfc2560bis
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, 27 Feb 2013 14:07:08 -0000

On 2/27/13 6:22 AM, Stefan Santesson wrote:
> Sean,
>
> Comments in line
>
> On 2/22/13 5:55 PM, "Sean Turner"  wrote:
>
>> Two things I think we should discuss and a couple of comments:
>>
>> Discuss 1) s4.3: I totally agree with upgrading RSA with SHA-256 to a
>> SHALL, but why are we updating RSA with SHA-1 to a SHALL?  With the
>> known weaknesses, I could see leaving it at SHOULD.
>
> This document includes the updates provided in RFC 6277 (Online
> Certificate Status Protocol Algorithm Agility) of June 2011.
> The rules you cite was the WG conclusion of that time.
>
> I think it is wise from an interop perspective to require that compliant
> clients must be able to "process" RSA with SHA-1 (which is the requirement
> in 4.3).
> That does not mean that an clients have to accept SHA-1 signed responses.
> They just need to have the capability.

I hate history sometimes, but it has been 1.5 years and SHA-1 isn't 
getting any stronger ;)

Why wouldn't a SHOULD would work from an interop perspective?  I'm thinking:

a) SHOULD is a do it unless you've got a really, really good reason not 
to.  And, that reason might be I've been installed in an environment 
that I know won't ever be be using SHA-1.

b) It kind of future proofs the spec to some degree because we know 
SHA-1 is on it's way out of favor because it's no longer recommended for 
digital signatures.

b) Going from SHOULD to MUST serves as notice to implementers that SHA-1 
one is likely going away in the future, which other protocols such as 
IPsec and S/MIME employed.

>> Discuss 2) s4.3: The MTI algs section made me think that we need to say
>> something about the key size as well.  Since we just had the same
>> discussion about S/MIME not too long ago I suggest taking some text from
>> RFC5751 s4.2/s4.3.
>
> I'm not convinced. As I see it, this section deals with interop and not
> security requirements for clients. For interop purposes it is normally
> sufficient to say RSA.
> Section 4.4.7 deals with the client's ability to specify it's Algorithmic
> and public Key requirements using SMIMECapability and AlgorithmIdentifier.
>
> You know that I hate hardcoding algorithm level requirements into protocol
> specs, and this discussion proves the point.
>
> We came to some conclusion in 6277 which was published less than 2 years
> ago.
> How long do you think it will take before any opinions on suitable
> algorithms expressed here is outdated?
>
> I would really like to see IETF doing a BCP on suitable algorithms that a
> document like this could refer to that would allow the BCP to be a living
> document.
> So much pain of this kind could be avoided.

Okay I can buy that rationale.

>> c1) In s1, it looks like a header is missing for section 1.1 or "1.1"
>> should be removed from the following:
>>
>> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>
> Fixed in a preliminary draft 14.

ack

>> c2) s2.6: r/Se further/See further
>
> Fixed in a preliminary draft 14.

ack

>> c3) s4.4.7.1: In the last paragraph r/4.4.7.1/4.4.7.2 otherwise it's a
>> circular reference ;)
>
> Fixed in a preliminary draft 14.

ack

>> c4) s4.4.7.2.1: Is it clearer to say the responder should pick the
>> highest precedence or the lowest numbered selection?  Just looking for
>> consistency between the paragraph before the list and the one after the
>> list.
>
> I know that this particular text was crafted after some discussion as
> result of an IESG discusses when publishing 6277.
> Therefore I'm a bit reluctant to change it unless I have an agreed
> replacement text.
>
> I think personally that it is clear as it is.

Roger that - no change required then.

> A preliminary draft 14 is available here:
> http://aaa-sec.com/_temp/rfc2560bis-14_01.txt
>
> Diff:
> http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-pki
> x-rfc2560bis-13.txt&url2=http://aaa-sec.com/_temp/rfc2560bis-14_01.txt

When we close on #1, I'll whack the LC button.

spt

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

From stefan@aaa-sec.com  Wed Feb 27 06:29:04 2013
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 D356121F867B for ; Wed, 27 Feb 2013 06:29:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.793
X-Spam-Level: 
X-Spam-Status: No, score=-101.793 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 yIDLFRWCJRtv for ; Wed, 27 Feb 2013 06:29:04 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 842F821F867D for ; Wed, 27 Feb 2013 06:29:02 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id E3A9C4B49E6 for ; Wed, 27 Feb 2013 15:29:00 +0100 (CET)
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 Ou_p-DJMWsT7 for ; Wed, 27 Feb 2013 15:29:00 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 636714B4A00 for ; Wed, 27 Feb 2013 15:29:00 +0100 (CET)
Received: (qmail 9163 invoked from network); 27 Feb 2013 14:29:00 -0000
Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.213]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Feb 2013 14:29:00 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Wed, 27 Feb 2013 15:28:58 +0100
From: Stefan Santesson 
To: Sean Turner 
Message-ID: 
Thread-Topic: [pkix] AD review of draft-ietf-pkix-rfc2560bis
In-Reply-To: <512E1307.5080901@ieca.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: pkix@ietf.org
Subject: Re: [pkix] AD review of draft-ietf-pkix-rfc2560bis
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, 27 Feb 2013 14:29:04 -0000

Sean,

Concerning SHA-1.

I know it is sad, but I still know government agencies that are using
SHA-1 for interop reasons because they have some system somewhere that
still don't know how to talk SHA-2.
The problem they have, or at least say they have, is that their process to
replace modules in the production environment are surrounded with
extensive processes in order to guarantee accurate and non-interrupted
services. So it's a matter of priority for them and apparently they are
not scared enough to assign the necessary resources. Even if they say that
they will go there eventually.

SHA-1 might still be sufficiently secure for many services and it is not
really the responsibility for a protocol to judge the operational security
requirements of its implementations.

I'm not confident that all systems would work perfectly if SHA-1 would be
taken out of the equation at this point.

As as for best current practices for security in services, I'd rather rely
on NIST, or BCPs than a static recommendation in a protocol standard.

/Stefan


On 2/27/13 3:07 PM, "Sean Turner"  wrote:

>On 2/27/13 6:22 AM, Stefan Santesson wrote:
>> Sean,
>>
>> Comments in line
>>
>> On 2/22/13 5:55 PM, "Sean Turner"  wrote:
>>
>>> Two things I think we should discuss and a couple of comments:
>>>
>>> Discuss 1) s4.3: I totally agree with upgrading RSA with SHA-256 to a
>>> SHALL, but why are we updating RSA with SHA-1 to a SHALL?  With the
>>> known weaknesses, I could see leaving it at SHOULD.
>>
>> This document includes the updates provided in RFC 6277 (Online
>> Certificate Status Protocol Algorithm Agility) of June 2011.
>> The rules you cite was the WG conclusion of that time.
>>
>> I think it is wise from an interop perspective to require that compliant
>> clients must be able to "process" RSA with SHA-1 (which is the
>>requirement
>> in 4.3).
>> That does not mean that an clients have to accept SHA-1 signed
>>responses.
>> They just need to have the capability.
>
>I hate history sometimes, but it has been 1.5 years and SHA-1 isn't
>getting any stronger ;)
>
>Why wouldn't a SHOULD would work from an interop perspective?  I'm
>thinking:
>
>a) SHOULD is a do it unless you've got a really, really good reason not
>to.  And, that reason might be I've been installed in an environment
>that I know won't ever be be using SHA-1.
>
>b) It kind of future proofs the spec to some degree because we know
>SHA-1 is on it's way out of favor because it's no longer recommended for
>digital signatures.
>
>b) Going from SHOULD to MUST serves as notice to implementers that SHA-1
>one is likely going away in the future, which other protocols such as
>IPsec and S/MIME employed.
>
>>> Discuss 2) s4.3: The MTI algs section made me think that we need to say
>>> something about the key size as well.  Since we just had the same
>>> discussion about S/MIME not too long ago I suggest taking some text
>>>from
>>> RFC5751 s4.2/s4.3.
>>
>> I'm not convinced. As I see it, this section deals with interop and not
>> security requirements for clients. For interop purposes it is normally
>> sufficient to say RSA.
>> Section 4.4.7 deals with the client's ability to specify it's
>>Algorithmic
>> and public Key requirements using SMIMECapability and
>>AlgorithmIdentifier.
>>
>> You know that I hate hardcoding algorithm level requirements into
>>protocol
>> specs, and this discussion proves the point.
>>
>> We came to some conclusion in 6277 which was published less than 2 years
>> ago.
>> How long do you think it will take before any opinions on suitable
>> algorithms expressed here is outdated?
>>
>> I would really like to see IETF doing a BCP on suitable algorithms that
>>a
>> document like this could refer to that would allow the BCP to be a
>>living
>> document.
>> So much pain of this kind could be avoided.
>
>Okay I can buy that rationale.
>
>>> c1) In s1, it looks like a header is missing for section 1.1 or "1.1"
>>> should be removed from the following:
>>>
>>> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>>>NOT",
>>
>> Fixed in a preliminary draft 14.
>
>ack
>
>>> c2) s2.6: r/Se further/See further
>>
>> Fixed in a preliminary draft 14.
>
>ack
>
>>> c3) s4.4.7.1: In the last paragraph r/4.4.7.1/4.4.7.2 otherwise it's a
>>> circular reference ;)
>>
>> Fixed in a preliminary draft 14.
>
>ack
>
>>> c4) s4.4.7.2.1: Is it clearer to say the responder should pick the
>>> highest precedence or the lowest numbered selection?  Just looking for
>>> consistency between the paragraph before the list and the one after the
>>> list.
>>
>> I know that this particular text was crafted after some discussion as
>> result of an IESG discusses when publishing 6277.
>> Therefore I'm a bit reluctant to change it unless I have an agreed
>> replacement text.
>>
>> I think personally that it is clear as it is.
>
>Roger that - no change required then.
>
>> A preliminary draft 14 is available here:
>> http://aaa-sec.com/_temp/rfc2560bis-14_01.txt
>>
>> Diff:
>> 
>>http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-p
>>ki
>> x-rfc2560bis-13.txt&url2=http://aaa-sec.com/_temp/rfc2560bis-14_01.txt
>
>When we close on #1, I'll whack the LC button.
>
>spt
>
>> /Stefan
>>
>>
>>>
>>> spt
>>> _______________________________________________
>>> 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 denis.pinkas@bull.net  Wed Feb 27 06:38:26 2013
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 2399321F8539 for ; Wed, 27 Feb 2013 06:38:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
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 3sZkJQ-X4O2y for ; Wed, 27 Feb 2013 06:38:25 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0F93221F84E8 for ; Wed, 27 Feb 2013 06:38:23 -0800 (PST)
Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id CD6FF1D33A; Wed, 27 Feb 2013 15:38:21 +0100 (CET)
Received: from [127.0.0.1] ([129.182.108.120]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2013022715382108-59822 ; Wed, 27 Feb 2013 15:38:21 +0100 
Message-ID: <512E1A5B.2040005@bull.net>
Date: Wed, 27 Feb 2013 15:38:19 +0100
From: Denis Pinkas 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Sean Turner 
References:  <512E1307.5080901@ieca.com>
In-Reply-To: <512E1307.5080901@ieca.com>
X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 27/02/2013 15:38:21, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 27/02/2013 15:38:21, Serialize complete at 27/02/2013 15:38:21
Content-Type: multipart/alternative; boundary="------------060906090008050000070509"
Cc: pkix@ietf.org, Stefan Santesson 
Subject: Re: [pkix] AD review of draft-ietf-pkix-rfc2560bis
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, 27 Feb 2013 14:38:26 -0000

This is a multi-part message in MIME format.
--------------060906090008050000070509
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Sean,

You said:

> When we close on #1, I'll whack the LC button.
>
> spt 

May I  recall you that I addressed comments during the WGLC which have 
not been addressed
to my satisfaction and that Stefan sent me a private answer on February 
11, 2013 which is copied below

At this time, Stefan has not yet send me a reply.

Denis

=======================================================================
Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC

Denis,

I will review your comments.
Unfortunately I won't be able to do so this week.

This document has already been sent to the IESG with a request for 
publication.
I will check in what way the comments will be handled.

/Stefan

From: Denis Pinkas >
Date: Monday, February 11, 2013 3:18 PM
To: Stefan Santesson >
Cc: pkix >
Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC

    Stefan,

    I have finally reviewed your disposition of comments. I have used
    draft 13.

    I will not address the comments in sequence, but I will consider
    four categories:

    *Category 1)*Some comments which seem to be solved. Yes indeed, they
    may be a few of them !

    *Category 2)*Some comments which might possibly be solved at the WG
    level.

    *Category 3)*Some comments that I will address at the IETF last call
    level, rather than the WG last call level, since I disagree
    that it is "new ways to say the same thing" and it is likely to be a
    waste of time for both of us to argue again at the WG level
    (these comments are commented as "not broken").

    *Category 4)*Some typos and editorials found while reading draft 13.

    *CATEGORY 1*

    *Comment 4*(was editorial).

    *Comment 5.*

    **

    *Comment 6. *

    *Comment 19*. Solved, since *"unknown"*seems now to be also allowed
    for non-issued certificates
    (even if the OCSP responder is using a direct access to the
    certificate database). See comment 8.

    *Comment 13*: Acceptable, since the text uses *"MAY".*

    *Comment 18. *

    *Comment 22.*

    *Comment 23.*

    *Comment 28.*

    *CATEGORY 1*

    *Comment 8*: You have changed the meaning of the revoked state in a
    way that is not what I requested.

    The original text was:

    *The "revoked" state indicates that the certificate has been revoked*

    *(either permanantly or temporarily (on hold)).*

    The new text is:

    **

    *    The "revoked" state indicates that the certificate has been revoked*

    *    either permanently or temporarily on hold (i.e. the revocation reason*

    *    is certificateHold).*

    By doing this, you do not allow any other case in the future to have
    a temporary revocation: "*temporarily on hold"**
    *is not the same as*"**temporarily revoked"**.*

    I propose the following rewording:

    *The "revoked" state indicates that the certificate has been revoked *

    *    either permanently or temporarily (e.g. placed on hold).*

    The way the text from draft 13 is now written seems to allow using
    either *"unknown"*or *"revoked"*for non-issued certificates.
    If this is the intent, then the good news is that this does not come
    anymore into conflict with the French rules which apply for
    the Administration since OCSP responders from CAs used by the French
    Ministries having a direct access to the database
    of issued certificates will be able to use *"unknown*", rather than
    *"revoked"*and the reason code *"onhold".*

    However, the current text is still mandating the use of *Extended
    Revoked Definition*, but the rational for its need it is very poor.
    As I have said on the PKIX list, the fact that the revocation date
    is January 1rst, 1970 is fully sufficient to know that we are in that
    very special case, and you have not provided a rational to say the
    contrary.

    So we could get rid of it, ... but the text from section 4.4.8 states:

    *    This extension MAY be present in other responses to signal that the*

    *    responder implements the extended revoked definition in section 2.2.*

    I have difficulties to understand what is really meant there ("other
    responses" ?), since the text states:

    *    This extension indicates that the responder supports the extended*

    *    definition of the "revoked" status to also include non-issued*

    *    certificates according to section 2.2.*

    Since both "unknown" and revoked" can be used, it would be desirable
    to be able to include the same extension in both cases,
    but in that case that extension should be renamed.

    I would propose to rename it: "*non-issued certificate*" which means
    that the associated CA has no record of ever having issued
    a certificate with the certificate serial number in the request (I
    still consider it as unnecessary in the case of "revoked", but it
    would be
    very useful in the case of "unknown"). Of course, the text from
    section 4.4.8 would need to be revised.

    I propose the following:

    *4.4.8   Non-issued certificate extension*

    *  *

    *    This extension MUST be included in the OCSP response when the OCSP*

    *    responder knows that the CA identified in the request has no record*

    *    of ever having issued a certificate with the certificate serial*

    *    number indicated in the request.*

    *  *

    *    Clients do not have to parse this extension in order to determine*

    *    the status of certificates in responses.*

    *  *

    *    This extension is identified by the object identifier id-pkix-ocsp-*

    *    non-issued-cert.*

    *  *

    *      id-pkix-ocsp-non-issued-cert OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}*

    *  *

    *    The value of the extension SHALL be NULL. This extension MUST NOT be*

    *    marked critical.*

    Then the text on page 8 would need to be rearranged.

    The current text is:

    *    This state MAY also be returned if the*

    *    associated CA has no record of ever having issued a certificate with*

    *    the certificate serial number in the request, using any current or*

    *    previous issuing key (referred to as a "non-issued" certificate in*

    *    this document).*

    *  *

    *    The "unknown" state indicates that the responder doesn't know about*

    *    the certificate being requested.*

    *  *

    *    NOTE: The "revoked" state for known non-issued certificate serial*

    *          numbers is allowed in order to reduce the risk of relying*

    *          parties using CRLs as a fall back mechanism, which would be*

    *          considerably higher if an "unknown" response was returned.*

    *  *

    *    When a responder responds revoked to a status request for a non-*

    *    issued certificate, the responder MUST include the extended revoked*

    *    definition response extension (section 4.4.8) in the response,*

    *    indicating that the OCSP responder supports the extended definition*

    *    of revoked state to also cover non-issued certificates. In addition,*

    *    the SingleResponse related to this non-issued certificate;*

    *  *

    *     - MUST provide the revocation reason certificateHold (6),*

    *  *

    *     - MUST specify the revocationTime January 1, 1970, and;*

    *  *

    *      - MUST NOT include a CRL References extension (section 4.4.2) or any*

    *       CRL Entry Extensions (section 4.4.5).*

    Proposed text for a replacement:

    *    The "unknown" state indicates that the responder doesn't know about*

    *    the certificate being requested.*

    *  *

    *    If the OCSP responder knows that CA identified in the request has*

    *    no record of ever having issued a certificate with the certificate*

    *    serial number in the request, using any current or previous issuing*

    *    key (referred to as a "non-issued" certificate in this document),*

    *    the OCSP responder SHALL respond either "revoked " or "unknown".*

    *  *

    *    Note: The "revoked" state for known non-issued certificate serial*

    *    numbers is allowed in order to reduce the risk of relying parties*

    *    using CRLs as a fall back mechanism, which would be possible when*

    *    the "unknown" response is returned.*

    *  *

    *    When a responder responds revoked or unknown to a status request*

    *    for a non-issued certificate, the responder MUST include the*

    *    non-issued certificate extension (see section 4.4.8) in the*

    *    response.*

    *  *

    *    When a responder responds revoked to a status request for a non-*

    *    issued certificate, in addition, the responder:*

    *  *

    *     - MUST provide the revocation reason certificateHold (6),*

    *  *

    *     - MUST specify the revocationTime January 1, 1970, and;*

    *  *

    *     - MUST NOT include a CRL References extension (section 4.4.2) or any*

    *       CRL Entry Extensions (section 4.4.5).*

    Finally, the last bullet on page 4 should be reworded:

    Current text:

    *       o Section 4.4.8 specifies a new extension that indicates that the*

    *          responder supports the extended use of the "revoked" response*

    *          for non-issued certificates defined in section 2.2.*

    **

    Proposed replacement text:

    *       o  Section 4.4.8 specifies a new extension that indicates that*

    *          the OCSP responder knows that CA identified in the request*

    *          has no record of ever having issued a certificate with the*

    *          certificate serial number present in the request, as defined*

    *          in section 2.2.*

    *Comment 9:*Solved, if the comment above may be solved.

    *Comment 20*:This comment is preliminary classified by you as "not
    broken". However, since you asked: "If you don't replace 4.2.2.3,
    then what really are you missing ?", I will provide you with an answer.

    This is the wrong way to state the question. Providing an ASN.1
    syntax as in 4.2.1 is not enough: the use of every parameter
    MUST be explained using English words. So if you explain the use of
    every parameter after the description of the ASN.1 syntax
    in section 4.2.1. then section 4.2.2.3 is no more needed and thus
    can be deleted.

    The answer to your question "what is really missing" is a
    description of the use of every parameter listed in the ASN.1 in
    section 4.2.1

    *Comment 21.*

    While I can agree in general with the intent of the text, I do not
    understand the first sentence of the Note which speaks of "CA key
    rollover"
    and is copied below:

    *    Note: CA key rollover is not prohibited when issuing a certificate*

    *          for an authorized responder for backwards compatibility with*

    *          RFC 2560 [RFC2560]. That is, it is not prohibited to issue a*

    *          certificate for an authorized responder using a different*

    *          issuing key than the key used to issued the certificate being*

    *          checked for revocation. However, such practice is strongly*

    *          discouraged since clients are not required to recognize a*

    *          responder with such certificate as an authorized responder.*

    I would propose to delete it, since it does not add anything and
    thus to have:

    *    Note: For backwards compatibility with RFC 2560 [RFC2560], it is*

    *          not prohibited to issue a certificate for an authorized*

    *          responder using a different issuing key than the key used to*

    *          issued the certificate being checked for revocation.*

    *          However, such practice is strongly discouraged since clients*

    *          are not required to recognize a responder with such*

    *          certificate as an authorized responder.*

    *Comment 24*: The ASN.1 module in annex B.1 is still wrong, since it
    does not define NoCheck.

    *Comment 26*: You asked for explanations. Let me provide you with an
    example when CRLs are being used by the OCSP responder
    in the background. The OCSP responder needs to make sure that the
    CRL it uses is valid. If it is simply using published CRLs
    (i.e. no trusted link with the CA), it needs to make sure that the
    CA which has issued the CRL has no been revoked.

    In France, there is a root CA for the Administration. However, the
    use of that root CA is optional. Thus a Ministry may have its own root,
    but may also have its key certified by the root CA of the
    Administration. The OCSP responder may use the root CA of the Ministry,
    while a relying party may use the root CA of the Administration (or
    the reverse) to validate the CRL for the target certificate.
    Thus the revocation status will be different if the certificate of
    the CA of the Ministry is revoked by the root CA of the Administration.

    *CATEGORY 3*

    *Comments*2, 3, 7, 10, 12, 14, 15, 16, 17, 25 and 27.

    *CATEGORY 4*

    Page 4. The indentation of the bullets in section 1 is not uniform.
    Bullets 1, 4, 5 and 9 have problems.

    Page 4. The fact that there is now an Annex B.2 dealing with the
    2008 ASN.1 syntax is missing. This should be added.

    Page 10. Change "*Se further section 4.2.2.2"*into "*See further
    section 4.2.2.2"
    *


    Denis
    **

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



>     Denis,
>
>     Responding to your comments below.
>
>     However, one general remark to make recurring comments easier to
>     understand.
>
>     The WG decided to adopt a minimalistic approach to updating RFC
>     2560. That means that
>
>      1. We don't change anything from RFC 2560 unless it is broken, or
>         the industry clearly need clarifications in order to avoid
>         interoperability issues.
>      2. We retain the document structure of RFC 2560 as much as
>         possible to allow easy comparison of what the changes are in
>         comparison with RFC 2560.
>
>
>     One can always think up more clever ways to write things out in
>     words. But that also comes with a risk.
>     The current words has been around for a long time and we know from
>     experience which words worked to produce working implementations,
>     and which did not.
>     Introducing new ways to say the same thing may introduce new
>     problems and people might disagree on what the new perfect wording
>     should be. And this could go on forever.
>
>     So when my reply is "Not broken", then that is because the current
>     wording does not have such problems that is merits a change.
>
>
>
>     From: Denis Pinkas      >
>     Date: Sunday, January 20, 2013 5:12 PM
>     To: Stefan Santesson      >, Stephen Kent      >
>     Cc: pkix >
>     Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC
>
>         Please find 32 comments on draft-ietf-pkix-rfc2560bis
>
>         1.The document states:
>
>         **         responded to separately>
>
>
>     Responded to separately.
>
>         2.The current text from section 2 states:
>
>         2.   Protocol Overview
>
>           
>
>             In lieu of or as a supplement to checking against a periodic CRL, it
>
>             may be necessary to obtain*timely information*  regarding the
>
>             revocation status of a certificate (cf. RFC5280], Section 3.3).
>
>             Examples include high-value funds transfer or large stock trades.
>
>           
>
>             The Online Certificate Status Protocol (OCSP) enables applications to
>
>             determine the (revocation) state of an identified certificate. OCSP
>
>             may be used to satisfy some of the operational requirements of
>
>             providing*more timely revocation information*  than is possible with
>
>             CRLs and may also be used to obtain additional status information.
>
>           
>
>         This text is misleading because readers may think that OCPS necessarily provides "timely information".
>
>           
>
>
>     "may" does not mean "necessarily".
>
>         Proposed text replacement:
>
>           
>
>         *The Online Certificate Status Protocol (OCSP) is a
>         client-server *
>
>         *protocol which enables applications to obtain the revocation
>         status *
>
>         *of one or more certificates either "good", "revoked", or
>         "unknown".*
>
>         **
>
>         *The revocation status may be provided by the server either
>         using a *
>
>         *real time access to a database of issued certificates, or
>         using a *
>
>         *batch access to a database of issued certificates, or using a *
>
>         *real time access to a database of revocation statuses of issued *
>
>         *certificates, or using a batch access to a database of
>         revocation *
>
>         *statuses of issued certificates, or using CRLs, or using a *
>
>         *combination of base CRLs and delta CRLs.*
>
>         **
>
>         *In the first case, it is possible to obtain timely revocation
>         status *
>
>         *information, whereas in the other cases, the freshness of the *
>
>         *revocation status is not better than the mechanisms it is
>         based on.*
>
>           
>
>           
>
>
>     Not broken
>
>         3.The current text from section 2 states:
>
>           
>
>             An OCSP client issues a status request to an OCSP responder and
>
>             Suspends acceptance of*the certificate in question*  until the
>
>             responder provides a response.
>
>           
>
>             This protocol specifies the data that needs to be exchanged between
>
>             an application checking the status of a certificate and the server
>
>             providing that status.
>
>           
>
>         Thus is insufficient for an overview. More details are needed to know what the document provides,
>         in particular that the request may contain several requests for several certificates issued by different CAs.
>         The possibility of using extensions should also be advertised.
>
>           
>
>         Proposed text replacement:
>
>           
>
>         When using OCSP, an OCSP client issues a certificate revocation
>
>         status request to an OCSP responder *for one or more
>         certificates *
>
>         *issued by the same CA or for one or more certificates issued by *
>
>         *different CAs *and then suspends acceptance of the
>         certificate(s)
>
>         in question until the responder provides a response.
>
>         This document specifies the data that needs to be exchanged
>         between
>
>         an application checking the status of a certificate and the server
>
>         providing that status.
>
>         *OCSP may also provide additional status information using *
>
>         *extensions. *
>
>
>     Not broken
>
>         4.Page 6. Editorial. Punctuation and a CR/LF are missing.
>
>         The text states:
>
>         *    3. the request contains the information needed by the responder If*
>
>         *       any one of the prior conditions are not met, the OCSP responder*
>
>         *       produces an error message; otherwise, it returns a definitive*
>
>         *       response.*
>
>         It should state:
>
>         *    4. the request contains the information needed by the responder.*
>
>         *  *
>
>         *       If any one of the prior conditions are not met, the OCSP responder*
>
>         *       produces an error message; otherwise, it returns a definitive*
>
>         *       response.*
>
>
>     Fixed in draft 10.
>
>         5.On page 7, the text states:
>
>         **
>
>         *All definitive response messages SHALL be digitally signed.
>         The key*
>
>         *used to sign the response MUST belong to one of the following:*
>
>         *  *
>
>         *    -   the CA who issued the certificate in question*
>
>         *    -   a Trusted Responder whose public key is trusted by the requester*
>
>         *    -   a CA Designated Responder (Authorized Responder) who holds a*
>
>         *       specially marked certificate issued directly by the CA, indicating*
>
>         *       that the responder may issue OCSP responses for that CA.*
>
>         **
>
>         The paragraph is ambiguous on several aspects.
>
>         Delegation is addressed in at least three different places,
>         but with different terms and conditions.
>         If some one picks a sentence in one paragraph rather than
>         another, it will lead to a different conclusion.
>         RFCs are supposed to be clear.
>
>         On page 10, the current text states in section*2.6 OCSP
>         Signature Authority Delegation *states:
>
>           
>
>         *The key that signs a certificate's status information need
>         not be the*
>
>         *same key that signed the certificate.**A certificate's issuer*
>
>         *explicitly delegates OCSP signing authority by issuing a
>         certificate*
>
>         *containing a unique value for extendedKeyUsage in the OCSP
>         signer's*
>
>         *certificate. This certificate MUST be issued directly to the*
>
>         *responder by the cognizant CA.*
>
>           
>
>         On page 16, there is a section *4.2.2.2***called*"**Authorized
>         Responders"*dealing with the same topic.
>
>         Section 4.2.2.2 states:
>
>         *The key that signs a certificate's status information need
>         not be the*
>
>         *same key that signed the certificate**. It is necessary
>         however to*
>
>         *ensure that the entity signing this information is authorized
>         to do*
>
>         *so.Therefore, a certificate's issuer MAY either sign the OCSP*
>
>         *responses itself or it MAY explicitly designate this
>         authority to*
>
>         *another entity.OCSP signing delegation SHALL be designated by
>         the*
>
>         *inclusion of id-kp-OCSPSigning in an extendedKeyUsage
>         certificate*
>
>         *extension included in the OCSP response signer's
>         certificate.This*
>
>         *certificate MUST be issued directly by the CA that issued the*
>
>         *certificate in question.*
>
>         **
>
>         *The CA SHOULD use the same issuing key to issue a delegation*
>
>         *certificate as was used to sign the certificate being checked
>         for*
>
>         *revocation. Systems relying on OCSP responses MUST recognize a*
>
>         *delegation certificate as being issued by the CA that issued the*
>
>         *certificate in question only if the delegation certificate
>         and the*
>
>         *certificate being checked for revocation was signed by the
>         same key.***
>
>         The last sentence above in yellow is the key sentence that is
>         missing in the two other sections.
>
>           
>
>         Most implementations only support the case where the OCSP Responder receives an OCSP certificate that is signed by the same key
>         that was used to sign the target certificate. They do not support the case where the OCSP Responder receives an OCSP certificate
>         that is signed by a key that is different from the one that was used to sign the target certificate.
>
>         It is inappropriate to have three sections dealing with the
>         same topic with a slightly different meaning.
>
>         It is proposed the following.
>
>         On page 7, after:
>
>         *    -   a CA Designated Responder (Authorized Responder) who holds a*
>
>         *       specially marked certificate issued directly by the CA, indicating*
>
>         *       that the responder may issue OCSP responses for that CA.*
>
>         it is proposed to add "(*see section 4.2.2.2 for further
>         details**)"*, so that the reader knows that more details are
>         provided later on.
>
>         Then we do not need two sections to address delegation which
>         start with the same sentence:
>
>
>         "*The key that signs a certificate's status information need
>         not be the same key that signed the certificate".*
>
>         **
>
>         It is thus proposed to delete section 2.6.
>
>         Section 4.2.2.2 will thus remain the single section providing
>         full details.
>
>           
>
>
>     I have added references to section 4.2.2.2 in the quoted sections
>     in 2.2 and 2.6.
>     (will be included in draft 11)
>
>
>         6.  Page 7, the text states:
>
>         *    A definitive response message is composed of:*
>
>         *  *
>
>         *    -   version of the response syntax*
>
>         *    -   name of the responder*
>
>         *    -   responses for each of the certificates in a request*
>
>         *    -   optional extensions*
>
>         *    -   signature algorithm OID*
>
>         *    -  signature computed across hash of the response*
>
>         This description does not fit with the ASN.1 syntax which is
>         detailed later on, and in particular:
>
>         *    ResponseData ::= SEQUENCE {*
>
>         *       version               [0] EXPLICIT Version DEFAULT v1,*
>
>         *       **responderID               ResponderID,*
>
>         *       producedAt                GeneralizedTime,*
>
>         *       responses                 SEQUENCE OF SingleResponse,*
>
>         *       responseExtensions    [1] EXPLICIT Extensions OPTIONAL }*
>
>         Proposed text replacement:
>
>         *A definitive response message is composed of:*
>
>         **
>
>         *- a response status and if there is no error, the following:*
>
>         *- the version of the response syntax,*
>
>         *- an identifier of the OCSP server,*
>
>         *- the time at which the response was produced,*
>
>         *- single responses for each of the target certificates,*
>
>         *- optional extensions,*
>
>         *- the signature algorithm OID,*
>
>         *- the signature computed across hash of the response, and*
>
>         *- optional certificates.*
>
>
>     This is an overview section. We ought not try to duplicate the
>     level of detail provided in the detailed protocol section.
>     A "definitive response" according to tho 2.1 is a response to an
>     error-free request, so your first remark is redundant.
>
>     I have added a note about time to the current list, and changed
>     "name" to identifier in bullet 2.
>     (will be included in draft 11)
>
>         7.The text states on page 7:
>
>         *The response for each of the certificates in a request
>         consists of*
>
>         **
>
>         *-target certificate identifier*
>
>         *-certificate status value*
>
>         *-response validity interval*
>
>         *-optional extensions*
>
>         However, there are no explanations for the purpose of these
>         parameters and how they should be processed.
>
>         There are also no explanations on how to process a single
>         response and how to verify that it is its presence within the
>         signed structure
>         is valid or not valid. This is a major deficiency of the
>         current description of RC 2560 where there is no explanation
>         on how to validate
>         a single response.
>
>         Text proposal to be added after:
>
>         *The purpose of the identifier of the OCSP server is to allow
>         OCSP *
>
>         *clients to find whether the definitive response was signed by
>         a CA *
>
>         *or by an OCSP Responder.*
>
>         **
>
>         *The identifier of the OCSP server SHOULD either be the name
>         or the *
>
>         *key from a CA, or the name or the key from a OCSP Responder.*
>
>         **
>
>         *Unless there exist local rules (which are outside the scope
>         of this *
>
>         *document) for verifying that a single response is correctly
>         signed, *
>
>         *the following applies:*
>
>         *When the identifier matches with the name of the CA which has
>         issued *
>
>         *the target certificate or corresponds to the key used to
>         issue the *
>
>         *target certificate, then a single response is correctly signed *
>
>         *only if the digital signature of the OCSP response is valid
>         using the *
>
>         *key used to sign the target certificate.*
>
>         **
>
>         *When the identifier does not match with the name of the CA
>         which has *
>
>         *issued the target certificate or does not correspond to the
>         key used *
>
>         *to issue the target certificate, then an single response is
>         correctly *
>
>         *signed only if :*
>
>         **
>
>         *(a) there exists in the response an OCSP certificate issued by *
>
>         *the CA which has issued the target certificate which is *
>
>         *signed by the same key as the one used to issue the *
>
>         *target certificate, and*
>
>         **
>
>         *(b) the digital signature of the OCSP response is valid using *
>
>         *the subjectPublicKey contained in this OCSP certificate.*
>
>
>     Not broken.
>     All of this is already covered by the document.
>
>         8.The text states on page 7:
>
>         The "revoked" state indicates that the certificate has been
>         revoked
>
>         *(either permanently or temporarily (on hold)). *This state
>         MAY also be
>
>         returned if the responder knows that the requested certificate has
>
>         *never been issued during the history of the associated CA
>         *using any
>
>         current or previous issuing key. **
>
>         The text is ambiguous because there are two embedded
>         parenthesis and it is unclear whether the inner parenthesis
>         means "i.e" or "e.g".
>         This single sentence may let think that on hold is the single
>         case for temporarily revocation. Since neither X.509 nor RFC
>         5280 address
>         the case of a temporary revocation in the context of an OCSP
>         response (but only in the context of CRLs), we are able to add
>         another case
>         of temporary revocation which will only apply in the context
>         of OCSP.
>
>         The above sentence using the terms"*never been issued during
>         the history of the associated CA*"does not capture the fact
>         that it could be issued in the future, hence why using"*not
>         yet been used"*would be more appropriate.
>
>         Finally, it would have been more logical to use "unknown". So
>         it is important to add a note to explain why we have chosen
>         that case for "legacy clients",
>         otherwise the people who have not participate to the exchanges
>         will not understand.
>
>         Proposed text replacement:
>
>             *The "revoked" state indicates that the certificate has been revoked,*
>
>         *    either permanently or temporarily.*
>
>           
>
>             A certificate may be temporarily revoked either because it is
>
>             placed on hold (*i.e. the revocation reason is certificateHold*) or
>
>             because the responder is able to know, using a positive list of
>
>             issued certificates, that the serial number from the requested
>
>             certificate has*not yet been used*  by the CA to issue a certificate
>
>             (*i.e. the revocation reason is notIssuedOrIrregularlyIssued*).
>
>           
>
>         *NOTE: The "revoked" state is used rather than the "unknown" state, to*
>
>         *       make sure that relying parties that were conformant to RFC 2560*
>
>         *       will not use CRLs as a fall back mechanism.*
>
>           
>
>
>     I removed the double parenthesis and adopted your clarification
>     with regard to "on hold".
>
>     The text in draft 10 has changed from what you have commented on.
>     I believe that text is better.
>
>     You "Note" has problems.
>
>      1. We do not prevent responders to respond "unknown" if their
>         assessment is that this is an appropriate response,
>         considering what they know about the requested serial number.
>         Thus the term "is used" is misleading.
>      2. This mechanisms does not "make sure" that the clients do
>         anything. It's up to the discretion of the relying party to
>         decide what source of revocation checking they rely on. This
>         does however reduce the risk of clients falling back to CRL:s
>      3. This mechanism is not just relevant to old clients, but also
>         to new one for the same reason.
>
>
>     I have adopted a modified version of your Note:
>
>        NOTE: The "revoked" state for known non-issued certificate serial
>              numbers is allowed in order to reduce the risk of relying
>              parties using CRLs as a fall back mechanism, which would be
>              considerably higher if an "unknown" response was returned.
>
>
>
>         9.The text states on page 8:
>
>         *When a responder responds revoked to a status request for a non-*
>
>         *issued certificate, the responder MUST also;*
>
>         **
>
>         *- include the extended revoked definition response extension*
>
>         *(section 4.8), indicating that the OCSP responder supports the*
>
>         *extended definition of revoked state to also cover non-issued*
>
>         *certificates,*
>
>         **
>
>         *- provide the revocation reason certificateHold (6), and;*
>
>         **
>
>         *- specify the revocation date January 1, 1970. *
>
>         As already explained on the PKIX list, using the revocation
>         reason**certificateHold is not appropriate
>         because it changes the meaning of certificateHold.
>
>         The extended revoked definition response extension is a means
>         to signal that it not a true certificate hold but a "not
>         issued certificate".
>         Legacy applications cannot take advantage of it.
>
>         Some applications which handle non repudiation enter a waiting
>         state when the revocation reason certificateHold is used thus
>         it is not appropriate to overload the meaning.
>
>         **
>
>         It is possible to use another enumeration for signalling that
>         specific case:
>
>         notIssuedOrIrregularlyIssued (7).
>
>         **
>
>         Thus for new applications it would be much better to use
>         notIssuedOrIrregularlyIssued (7) as already proposed on the
>         PKIX list.
>
>         The above sentence uses the text:  
>
>           
>
>         "a status request for a*non-issued certificate*"
>
>           
>
>         whereas it would be more appropriate to state:  
>
>           
>
>         "a status request for a*  serial number which has not been used by the CA or used irregularly to issue a certificate".*
>
>         *  *
>
>         Placing the ASN.1 description at such a place in the document is inappropriate since the ASN.1 structures have not yet been described.
>         Thus only the functional aspects should be mentioned, but not the ASN.1 implications.
>
>         *  *
>
>         BTW, the description should follow the same order as the ASN.1. This is not the case.
>
>           
>
>         This text should be deleted from this section and the appropriate text should be added when the parameters of the response are described.
>
>           
>
>         The text proposed in the previous comment should be sufficient at this time of reading.
>
>           
>
>         In addition, section*4.4.8Extended Revoked Definition *should
>         be deleted.**
>
>           
>
>           
>
>
>     The referred text has been updates in draft 09.
>
>     This has been discussed on the list and you have yet to convince
>     the list of your new reason code.
>     I disagree as the risk of running into problems with the deployed
>     base of application is hugely larger with introduction of a new
>     reason code, rather than using certificateHold.
>     No application should be broken, since no application have
>     business asking for non-issued cert serial numbers in the first
>     place. Secondly, no application can assume that a certificateHold
>     reason will be cleared any time soon.
>
>
>         10.The text states on page 8:
>
>         *2.4Semantics of thisUpdate, nextUpdate and producedAt*
>
>         This section is misplaced. At this time of reading, the reader
>         does not know that thisUpdate, nextUpdate and producedAt are
>         values
>         used by the ASN.1 structures. It is appropriate to describe
>         what theses parameters mean when the ASN.1 syntax is described.
>         The current ASN.1 syntax is very badly described. One would
>         expect that after every ASN.1 structure description every
>         parameter is described.
>         Unfortunately this is not the case.
>
>         The text from this section is not aligned with the text that
>         is present in section 4.2.2.1.
>
>         In particular, in section 2.4:
>
>         **
>
>         *If nextUpdate is not set, the responder is indicating that newer*
>
>         *revocation information is available all the time.*
>
>         While in section 4.2.2.1:
>
>         *Responses where the nextUpdate value is not set are equivalent *
>
>         *to a CRL with no time for nextUpdate (see Section 2.4).*
>
>         It is not appropriate to have two different descriptions in
>         two different places.
>
>         Delete section 2.4. See comment number 19 for the description
>         of these parameters.
>
>
>     Not broken.
>     The current text segments fits well into a protocol overview section.
>
>         11.Section 2.5 is also misplaced. They use values from the
>         ASN.1 syntax which has not yet been described.
>         They should be moved or incorporated in the document once the
>         ASN.1 description has been done.
>
>
>     Not broken.
>
>         12.Remainder: Section 2.6 should be deleted (see comment
>         number 5).
>
>
>     Not broken.
>
>         13.Section 2.7 states:
>
>         *2.7CA Key Compromise*
>
>         **
>
>         *If an OCSP responder knows that a particular CA's private key
>         has*
>
>         *been compromised, it MAY return the revoked state for all*
>
>         *certificates issued by that CA.*
>
>         This section is misleading and should be removed. The reason
>         is the following:
>
>         The relying party must verify that the singleResponse is
>         signed by a responder which is entitled to do so.
>
>         a) If the CA key has been compromised and if the response is
>         signed by that CA key then the singleResponse will be discarded
>         when performing the certification path validation _whatever
>         the content of the response may be_.
>
>         b) If the CA key which has issued the OCSP certificate has
>         been compromised and if the response is signed by the key present
>         in the OCSP certificate then the singleResponse will be
>         discarded when performing the certification path validation
>         _whatever the content of the response may be_.
>
>         Security must be provided using the validation of the
>         certification path. Thus it does not matter what the OCSP
>         responder states.
>
>
>
>     Not broken.
>     An OCSP responder does not have to be chained to the broken CA.
>     The relying party may have other trust configuration at choice.
>
>
>
>         14.The text states on page 11:
>
>         *3.2Signed Response Acceptance Requirements*
>
>         **
>
>         *Prior to accepting a signed response as valid, OCSP clients
>         SHALL*
>
>         *confirm that:*
>
>         **
>
>         *1. The certificate identified in a received response
>         corresponds to*
>
>         *that which was identified in the corresponding request;*
>
>         **
>
>         *2. The signature on the response is valid;*
>
>         **
>
>         *3. The identity of the signer matches the intended recipient
>         of the*
>
>         *request.*
>
>         **
>
>         *4. The signer is currently authorized to sign the response.*
>
>         **
>
>         *5. The time at which the status being indicated is known to be*
>
>         *correct (thisUpdate) is sufficiently recent.*
>
>         **
>
>         *6. When available, the time at or before which newer
>         information will*
>
>         *be available about the status of the certificate (nextUpdate) is*
>
>         *greater than the current time.*
>
>         This section is misplaced since it uses terms from the ASN.1
>         syntax and the protocol description has not yet been made,
>         since it is the next section 4. Its text is not correct either.
>
>         This description does not take into account the fact that
>         a*BasicOCSPResponse *may contain one or several
>         *SingleResponses. *
>         In particular, the sentence"*The signer is currently
>         authorized to sign the response*" is misleading because a signer
>         may be authorized to include some***SingleResponses *but not
>         necessarily all of them.
>
>         The appropriate explanations should be done after the
>         description of the response, when describing the processing of
>         the response.
>
>         Delete that section.
>
>
>     Not broken.
>
>         15.On page 12, after the ASN.1 description, the only
>         parameters which are described are:
>
>         *hashAlgorithm,**issuerNameHash, issuerKeyHash and serialNumber.*
>
>         **
>
>         This is insufficient.In order to cover the full list of
>         parameters, the following text is proposed:
>
>         *requestorName is optional and MAY be used by the server for
>         access *
>
>         *control and audit purposes.*
>
>         **
>
>         *requestList contains one or more single requests.*
>
>         **
>
>         *requestExtensions is OPTIONAL.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.*
>
>         **
>
>         *reqCert contains the identifier of a target certificate.*
>
>         **
>
>         *issuerNameHash is the hash of the Issuer's distinguished
>         name.The *
>
>         *hash shall be calculated over the DER encoding of the
>         issuer's name *
>
>         *field in the certificate being checked. *
>
>         **
>
>         *issuerKeyHash is the hash of the Issuer's public key.The hash *
>
>         *shall be calculated over the value (excluding tag and length)
>         of the *
>
>         *subject public key field in the issuer's certificate.The hash *
>
>         *algorithm used for both these hashes, is identified in *
>
>         *hashAlgorithm. *
>
>         **
>
>         *The primary reason to use the hash of the CA's public key in *
>
>         *addition to the hash of the CA's name, to identify the issuer, *
>
>         *is that it is possible that two CAs may choose to use the same *
>
>         *name (uniqueness in the Name is a recommendation that cannot be *
>
>         *enforced). Two CAs will never, however, have the same public
>         key *
>
>         *unless the CAs either explicitly decided to share their private *
>
>         *key, or the key of one of the CAs was compromised.*
>
>         **
>
>         *serialNumber is the serial number of the certificate for which *
>
>         *status is being requested.*
>
>         **
>
>         *singleRequestExtensions is OPTIONAL.Any specific extension is *
>
>         *OPTIONAL.The critical flag SHOULD NOT be set for any of them. *
>
>         **
>
>         *The requestor MAY choose to sign the OCSP request.In that
>         case, the*
>
>         *signature is computed over the tbsRequest structure.If the
>         request*
>
>         *is signed, the requestor SHALL specify its name in the
>         requestorName*
>
>         *field.Also, for signed requests, the requestor MAY include*
>
>         *certificates that help the OCSP responder verify the requestor's*
>
>         *signature in the certs field of Signature.*
>
>
>     Not broken.
>     The current text is short, but it is actually sufficient from the
>     context of the ASN.1 definitions of the section. This is a
>     detailed protocol section and the reader need to understand ASN.1
>     in any case to understand and implement the section.
>     The information about criticality is already covered in the
>     extension section.
>
>
>         16.Section 4.1.2 is called:"*Notes on the Request Syntax"*
>
>         The first paragraph has been moved after the description
>         of*issuerKeyHash *and thus is no more needed.
>
>         The second paragraph has been moved after the description
>         of*requestExtensions. *
>         However, the sentence
>         " *Unrecognized extensions MUST be ignored (unless they have
>         the critical flag set and are not understood)*"
>         has been deleted since it applies to the OCSP responder and
>         not to the OCSP client. Thus it is no more needed.
>
>         The third paragraph applies to signed requests. However, it
>         should belong to a section dedicated on how clients should
>         build OCPS requests,
>         which is currently missing. See the next comment.
>
>         This section should be deleted.
>
>
>     Not broken.
>
>         17.There should be a new section called: "*Requirements for
>         OCSP clients". *
>
>         It is important first to re-advertise that the request may be
>         about several certificates.
>         Thus it is important to describe the process for building a
>         request, which is currently missing.
>
>         *An OCSP request allows getting in the same response the
>         revocation *
>
>         *status of one or more certificates.In order to request the *
>
>         *status of one or more certificates in a single request, OCSP *
>
>         *clients SHALL follow the following rules :*
>
>         **
>
>         *For each candidate certificate, OCSP clients SHALL verify *
>
>         *whether there exists a locally defined rule for the
>         certificate in *
>
>         *question which indicates the URI where the OCSP responder is *
>
>         *located.If this rule exists, it SHALL be followed. *
>
>         **
>
>         *Otherwise, OCSP clients SHALL determine whether the candidate *
>
>         *certificate contains an AIA extension with an accessMethod
>         which *
>
>         *contains the id-ad-ocsp OID.If it is the case, the
>         accessLocation *
>
>         *contains a uniformResourceIdentifier (URI) which indicates the *
>
>         *location of the OCSP server for that certificate. *
>
>         **
>
>         *Certificates that contain the same URI MAY be grouped in a
>         single *
>
>         *request.*
>
>         **
>
>         *Note:For each candidate certificate, when performing the path *
>
>         *validation algorithm, the OCSP client SHOULD verify that the *
>
>         *current time is within the validity period of the target *
>
>         *certificate.Certificates which are outside their validity *
>
>         *period SHOULD NOT be included in the request.*
>
>         *The requestor MAY choose to sign the OCSP request. In that
>         case, the*
>
>         *signature is computed over the tbsRequest structure. If the
>         request*
>
>         *is signed, the requestor SHALL specify its name in the
>         requestorName*
>
>         *field. Also, for signed requests, the requestor MAY include*
>
>         *certificates that help the OCSP responder verify the requestor's*
>
>         *signature in the certs field of Signature.*
>
>
>     Not broken.
>
>     Your text may provide guidance that could be useful to some
>     implementers, but is completely beyond this document and further,
>     not generally applicable or true.
>     As an example, an organisation may setup an in house locally
>     configured OCSP responder that responds to all certificates "out
>     there" that is relevant to that organisation.
>     Such clients would just blindly send OCSP requests to their local
>     responder, disregarding any information in the cert.
>     It's totally beyond this spec to have an opinion about this.
>
>
>         18.The text states on page 14:
>
>         *The responder MAY include certificates in the*
>
>         *certs field of BasicOCSPResponse that help the OCSP client
>         verify the*
>
>         *responder's signature. If no certificates are included then
>         certs*
>
>         *SHOULD be absent.*
>
>         While this sentence is true, it is not sufficient. In order to
>         allow verifying every *SingleResponse*,
>         it is important to include the relevant certificates which are
>         pertinent to every *SingleResponse.*
>
>         Proposed full text replacement:
>
>         The responder MAY include certificates in the certs field of
>
>         BasicOCSPResponse that help the OCSP client verify the
>         responder's
>
>         signature.
>
>         *For every SingleResponse where the responder is not a CA, the *
>
>         *responder SHALL include the relevant OCSP certificate in the
>         certs *
>
>         *field of BasicOCSPResponse in order to allow the OCSP client *
>
>         *verifying the responder was entitled to include that
>         SingleResponse *
>
>         *in the signed BasicOCSPResponse.*
>
>         **
>
>         **If no certificates are included then certs SHOULD be absent.
>
>
>     Not broken.
>
>     This requirement would break backwards compatibility with RFC 2560.
>     Further this would not be needed for a locally configured responder.
>
>         19.Page 15. The ASN.1 syntax should be changed in order to be
>         able to use the enumeration case 7 that is not used for CRLs.
>         This leads to the following change:
>
>         Current text:
>
>         **
>
>         *revocationReason[0]EXPLICIT CRLReason OPTIONAL }*
>
>         Proposed text change:
>
>         Current text:
>
>         **
>
>         *revocationReason [0]EXPLICIT RevocationReason OPTIONAL }*
>
>         *RevocationReason ::= ENUMERATED {*
>
>         *unspecified(0),*
>
>         *keyCompromise(1),*
>
>         *cACompromise(2),*
>
>         *affiliationChanged(3),*
>
>         *superseded(4),*
>
>         *cessationOfOperation(5),*
>
>         *certificateHold(6),*
>
>         *notIssuedOrIrregularlyIssued (7),*
>
>         *removeFromCRL(8),*
>
>         *privilegeWithdrawn(9),*
>
>         *aACompromise(10) }*
>
>
>     Not broken.
>
>     You have to convince the list about your new reason code.
>
>         20.Page 15. After the ASN.1 syntax, there is no description of
>         every parameter, neither on its use
>         (except a few words in section*4.2.2.1 Time *about*thisUpdate,
>         nextUpdate and producedAt).*
>
>         **
>
>         Every parameter needs to be described and explained.
>
>         **
>
>         *responderID indicates either the name or the key from a CA,
>         or the *
>
>         *name or the key from a OCSP Responder.*
>
>         **
>
>         *producedAt indicates the time at which this response was signed.*
>
>         **
>
>         *responses contains one or more single responses.*
>
>         **
>
>         *responseExtensions is OPTIONAL.Any specific extension is
>         OPTIONAL.*
>
>         *The critical flag may or may not be set.*
>
>         **
>
>         *certID is usually a copy of the same field which was placed
>         in the *
>
>         *request, but for OCSP responders which pre-produce signed
>         responses *
>
>         *certID may be the identifier of a target certificate that was
>         not *
>
>         *present in the request (see the end of section 4.2).*
>
>         **
>
>         *certStatus indicates the status of the certificate: either
>         good, *
>
>         *revoked or unknown.*
>
>         **
>
>         *thisUpdate indicates the time at which the status being
>         indicated *
>
>         *is known to be correct.*
>
>         **
>
>         *nextUpdate indicates the time at or before which newer
>         information *
>
>         *will be available about the status of the certificate.If *
>
>         *nextUpdate is not set, the server is indicating that newer *
>
>         *revocation information is available all the time. *
>
>         **
>
>         *If nextUpdate is set, it often corresponds to the {thisUpdate, *
>
>         *nextUpdate} interval in CRLs.Responses whose nextUpdate value
>         is *
>
>         *earlier than the local UTC time value SHOULD be considered *
>
>         *unreliable.Responses whose thisUpdate time is later than the
>         local *
>
>         *UTC time SHOULD be considered unreliable.*
>
>         **
>
>         *singleExtensions is OPTIONAL.Any specific extension is OPTIONAL.*
>
>         *The critical flag SHOULD NOT be set for any of them.*
>
>         **
>
>         *revocationTime indicates the time at which the certificate was *
>
>         *revoked.*
>
>         **
>
>         *revocationReason is OPTIONAL. It includes all the cases that
>         are *
>
>         *present in CRLReason used for CRLs and an additional case 7
>         which is*
>
>         *not used for CRLs.Case 7 is called
>         notIssuedOrIrregularlyIssued. *
>
>         **
>
>         *- "notIssued" corresponds to the case where the certificate *
>
>         *serial number that was sent was erroneous and has not yet *
>
>         *been used by the CA at the time of the query,*
>
>         **
>
>         *- "irregularlyIssued" corresponds to the case where the *
>
>         *certificate serial number that was sent really exists in a *
>
>         *certificate that is correctly signed, but to its knowledge *
>
>         *the CA has not issued a certificate with such a serial *
>
>         *number. As an example, it may have been issued by the CA *
>
>         *because the RA was compromised. *
>
>         **
>
>         *    When a responder responds revoked to a status request for which it*
>
>         *    knows that the serial number has not been used by the CA or has*
>
>         *    been irregularly used irregularly to issue a certificate, then*
>
>         *    in RevokedInfo the responder MUST:*
>
>         *  *
>
>         *          - specify the revocationTime :   January 1, 1970,*
>
>         *           - provide the revocationReason: notIssuedOrIrregularlyIssued (7).*
>
>         *  *
>
>         *    and in SingleResponse the responder MUST NOT include the nextUpdate.*
>
>         **
>
>         *The response MUST include a SingleResponse for each
>         certificate in*
>
>         *the request and SHOULD NOT include any additional SingleResponse*
>
>         *elements.However, there is one exception: *
>
>         **
>
>         *OCSP responders MAY pre-produce signed responses specifying the *
>
>         *status of certificates at a specified time.The time at which *
>
>         *the status was known to be correct SHALL be reflected in the *
>
>         *thisUpdate field of the response. *
>
>         **
>
>         *OCSP responders that pre-generate status responses MAY return *
>
>         *responses that include additional SingleResponse elements if*
>
>         *necessary to improve response pre-generation performance or
>         cache*
>
>         *efficiency (as permitted in [RFC5019]).*
>
>         Since the text above provides all the explanations at the
>         level of the ASN.1 parameters, the general text
>         from section*4.2.2.3 Basic Response *is no more need and
>         should be deleted.**
>
>         **
>
>
>     Preliminary I would say "not broken".
>     If you don't replace 4.2.2.3, then what really are you missing?
>
>         21.0n page 16, there is a section
>         *4.2.2.2***called*"**Authorized Responders"***
>
>         Section 4.2.2.2 states:
>
>         *(...)*
>
>         *This certificate MUST be issued directly by the CA that
>         issued the*
>
>         *certificate in question.*
>
>         **
>
>         *The CA SHOULD use the same issuing key to issue a delegation*
>
>         *certificate as was used to sign the certificate being checked
>         for*
>
>         *revocation. Systems relying on OCSP responses MUST recognize a*
>
>         *delegation certificate as being issued by the CA that issued the*
>
>         *certificate in question only if the delegation certificate
>         and the*
>
>         *certificate being checked for revocation was signed by the
>         same key.*
>
>         This section would need to reformatted to address CA
>         requirements first and then OCSP responder requirements:
>
>         *(...)*
>
>         *This certificate MUST be issued directly by the CA that
>         issued the*
>
>         *certificate in question.The CA SHOULD use the same issuing
>         key to *
>
>         *issue a delegation certificate as was used to sign the
>         certificate *
>
>         *being checked for revocation. *
>
>         **
>
>         *Systems relying on OCSP responses MUST _be able to_ recognize a *
>
>         *delegation certificate as being issued by the CA that issued
>         the *
>
>         *certificate in question if the delegation certificate and *
>
>         *the certificate being checked _were_ signed by the same key.*
>
>
>     I disagree. The CA is actually free to do anything, but cannot
>     expect the client to recognise the responder as authorised unless
>     the same private key is used.
>     The current text places the requirement where they belong.
>
>         22.On page 17, the text states:
>
>         *They MUST reject the*
>
>         *response if the certificate required to validate the
>         signature on the*
>
>         *response fails to meet at least one of the following criteria:*
>
>         This is ambiguous. It is inappropriate to have a negative
>         statement like"*They MUST reject". *
>         The sentence should be turned in the positive form"*They SHALL
>         accept"*
>
>         Since the ASN.1 syntax has now be described, it is possible to
>         be more specific.
>
>         The first occurrence of the word "response" should be changed
>         into "singleResponse", while the second occurrence
>         of the word "response" should be changed into "ResponseData"
>
>         Proposed text replacement:
>
>         *They SHALL accept a singleResponse if the certificate
>         required to *
>
>         *validate the signature placed on the ResponseData meets one
>         of the *
>
>         *following criteria:*
>
>
>
>     No, this change is not backwards compatible.
>     So state the requirements for rejection is not equivalent to
>     stating requirements for acceptance.
>     There may be other locally configured reasons to reject in
>     addition to those listed in the standard.
>
>
>         23.On page 17, the text states:
>
>         *3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage*
>
>         *extension and is issued by the CA that issued the certificate in*
>
>         *question as stated above."*
>
>         In order to be crystal clear, it is proposed to change the
>         wording in the following way:
>
>         *3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage*
>
>         *extension and was signed by the CA using the same key that used *
>
>         *to issue the certificate in question.*
>
>
>     No, issuing with another key is not prohibited, and may be
>     accepted by some clients as an authorised responder.
>
>         24.On page 17, the text states:
>
>         *This SHOULD be a non-critical extension. The value of the
>         extension *
>
>         *SHALL be NULL.*
>
>         **
>
>         The ASN.1 syntax is missing. Add:
>
>         **
>
>         *NoCheck ::= NULL*
>
>         **
>
>
>     Moving this to a separate discussion.
>     I'm not sure what the preferred way to describe this is.
>
>
>         25.Remainder: On page 18, the general text from
>         section***4.2.2.3 Basic Response***is no more needed and
>         should be deleted. See comment 20.
>
>         **
>
>
>     Not broken.
>
>         26.On page 24, text should be added to the Security
>         consideration section:
>
>         *Different results when using OCSP and CRLs*
>
>         **
>
>         *OCSP clients or verifiers must build and verify a
>         certification path *
>
>         *for each target certificate up to a trusted root.When an OCSP *
>
>         *Responder is using published CRLs, it must also build and
>         verify a *
>
>         *certification path for the CRLs it uses up to a trusted root.*
>
>         **
>
>         *However, it should be realized that the root used by an OCSP *
>
>         *Responder to verified these CRLs is not necessarily the same
>         as the *
>
>         *one that would be used by the OCSP client, if it were going
>         to verify *
>
>         *the CRLs itself.Hence the revocation status may not be
>         identical *
>
>         *in both cases.*
>
>         **
>
>         **
>
>
>     I don't understand this one.
>
>         27.On page 24, text should be added to the Security
>         consideration section:
>
>         **
>
>         *Denial of service attack using a flood of queries*
>
>         **
>
>         *A denial of service vulnerability is evident with respect to
>         a flood *
>
>         *of queries.The production of a cryptographic signature *
>
>         *significantly affects response generation cycle time, thereby *
>
>         *exacerbating the situation. *
>
>         **
>
>         *The flood of queries may either come from a flood attack or
>         from the *
>
>         *fact that there are too many certificates supported by the
>         same OCSP *
>
>         *responder.In the later case, the number of queries can be *
>
>         *reduced by using a technique similar to the splitting of CRLs: *
>
>         **
>
>         *When a block of certificates have been issued with the same *
>
>         *accessLocation in the AIA extension field of these
>         certificates, *
>
>         *then the accessLocation should be changed.In this way, a given *
>
>         *OCSP server will only be responsible for a block of
>         certificates.*
>
>         **
>
>
>     If the security considerations section is talking about splitting
>     OCSP responders in this way, then the document itself need to
>     introduce the subject.
>     I would suggest that it is beyond this update to do so.
>
>         **
>
>         28.On page 31, the text states.
>
>         *An alternative to this module that conforms to the 2002
>         version of *
>
>         *ASN.1 may be found in Section 4 of [RFC5912]. *
>
>         **
>
>         RFC 5912 omits to define the nocheck extension. Thus it is
>         inappropriate to refer to RFC 5912.
>
>         The corrected module should be defined in this new draft.
>         A corrected module is providedin *draft-pinkas-rfc2560bis-03.*
>
>
>     Will move this (as stated above) to a separate discussion.
>
>         29.Different topics are not covered by the document. These
>         topics are important.
>         The following comments propose text to be placed in annexes.
>         Three annexes are being proposed.
>
>         Note: The texts are extracted from*draft-pinkas-rfc2560bis-03.*
>
>
>     Not broken.
>     Each such amendment need to be thoroughly reviewed and motivated.
>
>
>         30.First annex being proposed. This annex is important,
>         because key rollover is not addressed in the draft.
>
>         *KEY ROLLOVER*
>
>         **
>
>         *1. CA that directly supports an OCSP service*
>
>         **
>
>         *When a CA that directly supports an OCSP service performs a key *
>
>         *rollover:*
>
>         **
>
>         *- for certificates issued under the old key, the CA SHALL
>         continue *
>
>         *to sign the revocation status of OCSP responses with that old
>         key *
>
>         *at least until all these certificates are expired, and*
>
>         **
>
>         *- for certificates issued under the new key, the CA SHALL
>         change the *
>
>         *accessLocation in the AIA extension field of these certificates *
>
>         *and sign the revocation status of OCSP responses with that
>         new key *
>
>         *at least until all these certificates are expired.*
>
>         **
>
>         *Note: The change in accessLocation is necessary when the CA
>         rekeys *
>
>         *to meet the following constraints imposed by this standard: *
>
>         **
>
>         *1) a BasicOCSPResponse can only be signed using a single *
>
>         *private key; *
>
>         **
>
>         *2) the response must be signed using the same CA key that *
>
>         *was used to sign the certificate in question; and*
>
>         **
>
>         *3) the OCSP response needs to cover all the certificates *
>
>         *queried in the OCSP request.*
>
>         *2. CA that uses OCSP responders*
>
>         *When a CA that uses OCSP Responders performs a key rollover,
>         then *
>
>         *it MUST either designate a new OCSP Responder or keep the
>         current *
>
>         *OCSP Responder(s).*
>
>         **
>
>         *If the CA designates a new OCSP Responder, then it SHALL
>         change the *
>
>         *accessLocation in the AIA extension field for the newly issued *
>
>         *certificates and issue an OCSP certificate to the new OCSP
>         Responder *
>
>         *using its new key.*
>
>         **
>
>         *If the CA keeps the same OCSP Responder(s), then it SHALL
>         continue *
>
>         *to use the same accessLocation(s) in the AIA extension field
>         for the *
>
>         *newly issued certificates and issue an OCSP certificate to the *
>
>         *appropriate OCSP Responder(s) using its new key.*
>
>         **
>
>         *Note: The CA may need to continue issuing certificates to the
>         OCSP *
>
>         *Responder(s) using the old CA key until all the certificates
>         issued *
>
>         *under the CA' old key for which the OCSP Responder(s) are *
>
>         *authoritative have expired.*
>
>         **
>
>         *3. OCSP Responder key rollover*
>
>         **
>
>         *When an OCSP Responder performs a key rollover
>         (asynchronously from *
>
>         *a CA key rollover), then each CA which has designated an OCSP *
>
>         *Responder SHALL issue a new certificate for that OCSP
>         Responder and *
>
>         *for each of its issuing keys which meets the following
>         property: *
>
>         **
>
>         *- the issuing key has been used to sign at least one
>         certificate *
>
>         *which contains an AIA extension designating that OCSP Responder *
>
>         *and that certificate is not yet expired.*
>
>         **
>
>         *An OCSP Responder key rollover does not affect the values of
>         the *
>
>         *URIs that are placed in the accessLocation field from the
>         target *
>
>         *certificates.One or more OCSP Responder MAY respond to an OCSP *
>
>         *request addressed at a given URI picked from the accessLocation *
>
>         *field from a target certificate.Each OCSP Responder MAY use a *
>
>         *different signing key, as long as it got an OCSP certificate *
>
>         *appropriate for that signing key and for the target
>         certificate. *
>
>         31.Second annex being proposed. This annex is important
>         because it describes the validation of an OCSP response in the
>         past
>         which is of a particular importance when validating electronic
>         signatures.
>
>         *Response processing by an OCSP client*
>
>         **
>
>         *OCSP responses can be verified at the current time by an OCSP
>         client *
>
>         *when receiving a response, whereas old responses can be
>         verified at *
>
>         *a time in the past by a verifier.The algorithm below addresses *
>
>         *both cases.*
>
>         **
>
>         *Prior to processing a basic response, OCSP clients MUST
>         determine *
>
>         *the checking time, which may be either the current time or a
>         time *
>
>         *in the past.*
>
>         **
>
>         *OCSP clients or verifiers SHALL check if the response contains *
>
>         *responseExtensions. If such an extension is found and is
>         recognized, *
>
>         *it MUST be processed.If such a critical extension is found and *
>
>         *is not recognized, the whole OCSP response MUST be considered
>         as *
>
>         *invalid.*
>
>         **
>
>         *If the checking time is the current time, and if a nonce
>         extension *
>
>         *has been used in the request and is recognized (see section
>         4.5.1), *
>
>         *OCSP clients MUST check whether the same nonce is present in
>         the *
>
>         *response.If the nonce is not present or is different, then the *
>
>         *OCSP response MUST be discarded.*
>
>         **
>
>         *Only the single response(s) which are/is of interest SHALL be *
>
>         *checked.*
>
>         **
>
>         *STEP 1*
>
>         **
>
>         *OCSP clients or verifiers SHALL verify that the certificate *
>
>         *identified in a single response is of interest.Otherwise,
>         proceed *
>
>         *to step 3.*
>
>         **
>
>         *If the certificate status included in a single certificate
>         response *
>
>         *is "unknown", then the revocation status of that certificate is *
>
>         *"unknown", and proceed to step 3.*
>
>         **
>
>         *If the certificate status from the single certificate
>         response is *
>
>         *either "good" or "revoked", OCSP clients or verifiers SHALL
>         check *
>
>         *that the checking time is within the validity period of the
>         target *
>
>         *certificate.If it is not the case, then the revocation status
>         of *
>
>         *that certificate is "unknown" and proceed to step 3.*
>
>         **
>
>         *If the checking time is the current time, and if a nonce has
>         been *
>
>         *used in the request, then proceed to step 2.*
>
>         **
>
>         *If the checking time is the current time, and if no nonce has
>         been *
>
>         *used in the request, OCSP clients MUST check that the producedAt*
>
>         *field is within a time window that is "close enough" to the
>         current *
>
>         *time. *
>
>         **
>
>         *Note: the notion of "close enough" is a local matter.It can
>         be set *
>
>         *to a few minutes to allow for small UTC time differences *
>
>         *between the client and the server or to a few hours in case *
>
>         *the server is producing pre-computed responses.*
>
>         **
>
>         *If the checking time is a time in the past, verifiers MUST
>         check *
>
>         *that the producedAt field is in accordance with the
>         verification *
>
>         *rules (e.g. close and/or after the date of a time-stamp token).*
>
>         **
>
>         *In addition, if the nextUpdate field is present, OCSP clients
>         MUST *
>
>         *check that the time which is indicated is greater than the
>         checking *
>
>         *time, otherwise the single response MUST be discarded.*
>
>         **
>
>         *If checks are successful, then OCSP clients MUST process the *
>
>         *singleExtensions field, if it is present. *
>
>         **
>
>         *If the criticality flag is set and the extension is not
>         understood, *
>
>         *then the status of the certificate shall be "unknown" and
>         proceed to *
>
>         *step 3.Otherwise, proceed to step 2. *
>
>         **
>
>         *If the extension is understood, then the extension MUST be *
>
>         *processed.According to its content proceed either to step 2
>         or to *
>
>         *step 3. *
>
>         **
>
>         *STEP 2*
>
>         **
>
>         *OCSP clients or verifiers MUST build and verify a
>         certification path *
>
>         *for that certificate up to a trusted root, so that they have
>         the *
>
>         *knowledge of the CA public key value that was used to sign the *
>
>         *target certificate.The revocation status of each certificate of *
>
>         *that certification path (except the target certificate) SHALL
>         be *
>
>         *checked.*
>
>         **
>
>         *If no path can be built or if one of the certificates of the
>         path is *
>
>         *revoked, then the revocation status of that certificate is
>         "unknown", *
>
>         *and proceed to step 3. *
>
>         **
>
>         *If the certification path (except the target certificate) is
>         valid, *
>
>         *then two cases need to be considered:*
>
>         **
>
>         *a) If the responderID matches with the name or the key from
>         the CA *
>
>         *which has issued the target certificate, then check whether the *
>
>         *OCSP response is signed by the same key that was used to sign *
>
>         *the target certificate.*
>
>         **
>
>         *If it is the case, then the revocation status of that *
>
>         *certificate as indicated in the certStatus field is *
>
>         *accepted and proceed to step 3.*
>
>         **
>
>         *If it is not the case, then the revocation status of that *
>
>         *certificate is "unknown" and proceed to step 3.*
>
>         **
>
>         *b) If the responderID does not match with the name or the key
>         from *
>
>         *the CA which has issued the target certificate, then it
>         indicates *
>
>         *the name or the key from an OCSP Responder.Check whether there *
>
>         *exists a local rule which applies to this target certificate to *
>
>         *verify that the signature of the BasicOCSPResponse is valid for *
>
>         *that single response.If this rule exists, it SHALL be followed. *
>
>         **
>
>         *Otherwise check whether there is an OCSP certificate (i.e.
>         which *
>
>         *has both the ocspSigning OID in the extended key usage
>         extension *
>
>         *and the digitalSignature bit in the key usage extension) signed *
>
>         *by the same key that was used to sign the target certificate. *
>
>         *This certificate MUST be present in the certs field from the *
>
>         *BasicOCSPResponse. *
>
>         **
>
>         *If such certificate is not found or is invalid, then the *
>
>         *revocation status of that certificate is "unknown" and *
>
>         *proceed to step 3.*
>
>         **
>
>         *If such certificate exists and if the checking time is *
>
>         *within the validity period of this certificate, then it MUST *
>
>         *be verified whether the OCSP response can be verified using *
>
>         *the public key that is present in the OCSP Certificate. *
>
>         **
>
>         *If it is not the case, then the revocation status of that *
>
>         *certificate is "unknown" and proceed to step 3.*
>
>         **
>
>         *If it is the case, then it MUST be verified that the OCSP *
>
>         *Certificate has not been revoked.*
>
>         **
>
>         *If one of these conditions is met, then the status for the
>         target *
>
>         *certificate as indicated in the certStatus field is accepted, *
>
>         *otherwise the revocation status is "unknown".*
>
>         **
>
>         *STEP 3*
>
>         **
>
>         *If there exists another single certificate status response
>         for a *
>
>         *target certificate that is of interest, then proceed to step 1. *
>
>         *Otherwise the basic response is now processed.*
>
>         32.Third annex being proposed. This annex is important because
>         it provides guidance on how to build an OCSP responder in the
>         three cases.
>         Many text portions are similar, but three full texts are
>         provided in order to provide a better clarity for each of the
>         three cases.
>
>         *1. Request processing by OCSP servers*
>
>         **
>
>         *The behavior of an OCSP server will be different whether the
>         OCSP *
>
>         *server is a CA acting as an OCSP responder, is an OCSP
>         Responder *
>
>         *which received a delegation from one or more CAs, or is a
>         locally *
>
>         *trusted Responder.*
>
>         **
>
>         *1.1. Processing by a CA acting as an OCSP responder*
>
>         **
>
>         *The OCSP responder SHALL maintain a list of entries. Each entry *
>
>         *SHALL contain:*
>
>         **
>
>         *- the URI associated to the OCSP responder, from which the OCSP *
>
>         *requests are received, *
>
>         **
>
>         *- the DN from a CA,*
>
>         **
>
>         *- an issuing public key from a CA,*
>
>         **
>
>         *- the method(s) used to know for which subset of certificates *
>
>         *issued by the CA it is responsible for, *
>
>         **
>
>         *- the method(s) used to obtain the revocation status of that *
>
>         *subset of certificates issued under that CA issuing public key, *
>
>         *and*
>
>         **
>
>         *- the method used to gain access and sign with the private key *
>
>         *corresponding to the issuing public key.*
>
>         **
>
>         *For a given URI value, the OCSP responder SHALL only use one CA *
>
>         *key pair value. *
>
>         **
>
>         *When it receives an OCSP request on that URI, the OCSP
>         responder *
>
>         *SHALL handle exceptions according to section 2.3. *
>
>         **
>
>         *If the OCSP request contains the name of a requestor, the OCSP *
>
>         *responder SHALL verify whether there exists a locally defined
>         rule *
>
>         *which regulates access control.If this rule exists, it SHALL be *
>
>         *followed.*
>
>         **
>
>         *Then, for each target certificate, the OCSP responder SHALL
>         verify *
>
>         *whether both the hash of the issuer's DN and the hash of the
>         issuer *
>
>         *public key which are present in the request are eligible to a *
>
>         *locally defined rule which indicates that the OCSP responder is *
>
>         *responsible to provide the revocation status of that target *
>
>         *certificate.If this rule exists, it SHALL be followed.*
>
>         **
>
>         *Otherwise, the OCSP responder SHALL determine whether it is *
>
>         *responsible to provide the revocation status of that target *
>
>         *certificate according to the following rule.*
>
>         **
>
>         *For each target certificate, the OCSP responder SHALL verify
>         whether *
>
>         *both the hash of the issuer's DN and the hash of the issuer
>         public *
>
>         *key which are present in the request match respectively with
>         the DN *
>
>         *and the hash of the public key of contained in an entry from
>         the *
>
>         *list of entries maintained by this OCSP responder. *
>
>         **
>
>         *When there is no match, then the OCSP responder SHALL
>         indicate the *
>
>         *"unknown" status and proceed with the next target certificate
>         from *
>
>         *the OCSP request.*
>
>         **
>
>         *When there is a match, then the OCSP responder SHALL use the
>         serial *
>
>         *number of the target certificate that is present in the
>         request and *
>
>         *determine the revocation status of that certificate according
>         to *
>
>         *the method(s) defined in the entry. *
>
>         **
>
>         *When the revocation status is provided by the server using a
>         real *
>
>         *time access to a database of revocation statuses of issued *
>
>         *certificates, then the thisUpdate field SHALL be present in the*
>
>         *SingleResponse response whereas the nextUpdate field SHALL be *
>
>         *missing. *
>
>         **
>
>         *Otherwise, both the thisUpdate and the nextUpdate fields
>         SHALL be *
>
>         *present in the SingleResponse. *
>
>         **
>
>         *The time at which this response will be signed MUST be
>         indicated in *
>
>         *the producedAt field from the SingleResponse.*
>
>         **
>
>         *If a singleRequestExtensions is present in the request it
>         MUST be *
>
>         *processed.*
>
>         **
>
>         *If there is another target certificate present in the
>         request, it *
>
>         *SHALL be processed in the same way.*
>
>         **
>
>         *If a requestExtensions is present in the request it MUST be *
>
>         *processed.*
>
>         **
>
>         *The OCSP response MUST be signed using the CA issuing private
>         key.*
>
>         **
>
>         **
>
>         *1.2. Processing by an OCSP Responder*
>
>         **
>
>         *For each CA from which the OCSP Responder has received a
>         delegation, *
>
>         *the OCSP Responder SHALL maintain a list of entries. *
>
>         **
>
>         *Each entry SHALL contain:*
>
>         **
>
>         *- the URI associated to this OCSP Responder, from which the
>         OCSP *
>
>         *requests are received, *
>
>         **
>
>         *- the DN from a CA,*
>
>         **
>
>         *- an issuing public key from a CA,*
>
>         **
>
>         *- the method(s) used to know for which subset of certificates *
>
>         *issued by the CA it is responsible for, *
>
>         **
>
>         *- the method(s) used to obtain the revocation status of that *
>
>         *subset of certificates issued under that CA issuing public key,*
>
>         **
>
>         *- an OCSP certificate, *
>
>         **
>
>         *- the OCSP public key contained in that OCSP certificate, and*
>
>         **
>
>         *- the method used to gain access and sign with the OCSP private *
>
>         *key corresponding to that OCSP certificate.*
>
>         **
>
>         *For a given URI value, the OCSP Responder SHALL only use one
>         OCSP *
>
>         *key pair value.Therefore there cannot be two entries with the *
>
>         *same URI value and a different OCSP public key value.*
>
>         **
>
>         *NOTE: a BasicOCSPResponse can only be signed using a single
>         private *
>
>         *key. *
>
>         **
>
>         *The OCSP certificate SHALL be signed by the CA issuing
>         private key *
>
>         *which corresponds to the issuing CA public key that is in this *
>
>         *entry.*
>
>         **
>
>         *When it receives an OCSP request, the OCSP responder SHALL
>         handle *
>
>         *exceptions according to section 2.3. *
>
>         **
>
>         *If the OCSP request contains the name of a requestor, the OCSP *
>
>         *responder SHALL verify whether there exists a locally defined
>         rule *
>
>         *which regulates access control.If this rule exists, it SHALL be *
>
>         *followed.*
>
>         **
>
>         *For each target certificate, the OCSP Responder SHALL verify *
>
>         *whether both the hash of the issuer's DN and the hash of the
>         issuer *
>
>         *public key which are present in the OCSP request match with
>         those *
>
>         *from an entry.*
>
>         **
>
>         *When there is no match, then the OCSP Responder SHALL
>         indicate the *
>
>         *"unknown" status and proceed with the next target certificate
>         from *
>
>         *the OCSP request.*
>
>         **
>
>         *When there is a match, the OCSP Responder SHALL use the serial *
>
>         *number of the target certificate this is present in the OCSP *
>
>         *request to determine the revocation status of that certificate *
>
>         *according to the method(s) indicated in the entry. *
>
>         **
>
>         *When the revocation status is provided by the server using a
>         real *
>
>         *time access to a database of revocation statuses of issued *
>
>         *certificates, then the thisUpdate field SHALL be present in the*
>
>         *SingleResponse response whereas the nextUpdate field SHALL be *
>
>         *missing. *
>
>         **
>
>         *Otherwise, both the thisUpdate and the nextUpdate fields
>         SHALL be *
>
>         *present in the SingleResponse. *
>
>         **
>
>         *The time at which this response will be signed MUST be
>         indicated in *
>
>         *the producedAt field from the SingleResponse.*
>
>         **
>
>         *If a singleRequestExtensions is present in the request it
>         MUST be *
>
>         *processed.*
>
>         **
>
>         *If there is another target certificate present in the
>         request, it *
>
>         *SHALL be processed in the same way.*
>
>         **
>
>         *If a requestExtensions is present in the request it SHALL be *
>
>         *processed.*
>
>         **
>
>         *The OCSP response MUST be signed using the OCSP private key.*
>
>         **
>
>         *Unless there is a local rule which states differently, for
>         every *
>
>         *target certificate which matches both with the hash of a CA
>         DN and an *
>
>         *issuing public key from an entry, the OCSP certificate of
>         that entry *
>
>         *SHALL be placed in the certs field.*
>
>         **
>
>         *It may happen, that none of the target certificates from the
>         OCSP*
>
>         *request matches both with the hash of a CA DN and an issuing
>         public *
>
>         *key from an entry.In that case and unless a local rule states *
>
>         *differently, the certs field from the BasicOCSPResponse
>         SHOULD be *
>
>         *kept empty (to limit the disclose of the names of the CAs
>         from which *
>
>         *the OCSP Responder received a delegation from).*
>
>         **
>
>         *1.3. Processing by a locally trusted Responder*
>
>         **
>
>         *For each CA for which the locally trusted Responder is *
>
>         *authoritative, the OCSP Responder SHALL maintain a list of
>         entries. *
>
>         **
>
>         *Each entry SHALL contain:*
>
>         **
>
>         *- the URI associated to this OCSP Responder, from which the
>         OCSP *
>
>         *requests are received, *
>
>         **
>
>         *- the DN from a CA,*
>
>         **
>
>         *- an issuing public key from a CA,*
>
>         **
>
>         *- the method(s) used to know for which subset of certificates *
>
>         *issued by the CA it is responsible for, *
>
>         **
>
>         *- the method(s) used to obtain the revocation status of that *
>
>         *subset of certificates issued under that CA issuing public key,*
>
>         **
>
>         *- the method used to gain access to the private key in order to *
>
>         *sign the OCSP response. *
>
>         **
>
>         *For a given URI value, the OCSP Responder SHALL only use one
>         private *
>
>         *key.Therefore there cannot be two entries with the same URI
>         value *
>
>         *and a different method to gain access to the appropriate
>         private key.*
>
>         **
>
>         *NOTE: a BasicOCSPResponse can only be signed using a single
>         private *
>
>         *key. *
>
>         **
>
>         *When it receives an OCSP request, the OCSP responder SHALL
>         handle *
>
>         *exceptions according to section 2.3. *
>
>         **
>
>         *If the OCSP request contains the name of a requestor, the OCSP *
>
>         *responder SHALL verify whether there exists a locally defined
>         rule *
>
>         *which regulates access control.If this rule exists, it SHALL be *
>
>         *followed.*
>
>         **
>
>         *For each target certificate, the OCSP Responder SHALL verify *
>
>         *whether both the hash of the issuer's DN and the hash of the
>         issuer *
>
>         *public key which are present in the OCSP request match with
>         those *
>
>         *from an entry.*
>
>         **
>
>         *When there is no match, then the OCSP Responder SHALL
>         indicate the *
>
>         *"unknown" status and proceed with the next target certificate
>         from *
>
>         *the OCSP request.*
>
>         **
>
>         *When there is a match, the OCSP Responder SHALL use the serial *
>
>         *number of the target certificate this is present in the OCSP *
>
>         *request to determine the revocation status of that certificate *
>
>         *according to the method(s) indicated in the entry. *
>
>         **
>
>         *When the revocation status is provided by the server using a
>         real *
>
>         *time access to a database of revocation statuses of issued *
>
>         *certificates, then the thisUpdate field SHALL be present in the*
>
>         *SingleResponse response whereas the nextUpdate field SHALL be *
>
>         *missing. *
>
>         **
>
>         *Otherwise, both the thisUpdate and the nextUpdate fields
>         SHALL be *
>
>         *present in the SingleResponse. *
>
>         **
>
>         *The time at which this response will be signed MUST be
>         indicated in *
>
>         *the producedAt field from the SingleResponse.*
>
>         **
>
>         *If a singleRequestExtensions is present in the request it
>         MUST be *
>
>         *processed.*
>
>         **
>
>         *If there is another target certificate present in the
>         request, it *
>
>         *SHALL be processed in the same way.*
>
>         **
>
>         *If a requestExtensions is present in the request it SHALL be *
>
>         *processed.*
>
>         **
>
>         *The OCSP response MUST be signed using the OCSP private key.*
>
>         **
>
>         *The certs field may contain no, one or several OCSP
>         certificates *
>
>         *according to local rules followed by the locally trusted
>         Responder.*
>
>
>     Not broken.
>
>     /Stefan
>
>         End of comments
>
>
>         Denis
>



--------------060906090008050000070509
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=ISO-8859-1


  
    
  
  
    
Sean,

      

      You said:

      

    

    
When we
      close on #1, I'll whack the LC button.
      

      

      spt
    

    

    May I  recall you that I addressed comments during the WGLC which
    have not been addressed 

    to my satisfaction and that Stefan sent me a private answer on
    February 11, 2013 which is copied below

    

    At this time, Stefan has not yet send me a reply.

    

    Denis

    

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

    
Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC

      

      Denis,

    


    

    
I will review your comments.

    
Unfortunately I won't be able to do so this week.

    


    

    
This document has already been sent to the IESG with a request
      for publication.

    
I will check in what way the comments will be handled.

    


    

    
/Stefan

    


    

    
      
From: 
        Denis Pinkas <denis.pinkas@bull.net>

        Date:  Monday, February
        11, 2013 3:18 PM

        To:  Stefan Santesson
        <stefan@aaa-sec.com>

        Cc:  pkix <pkix@ietf.org>

        Subject:  Re: [pkix]
        Review of 2560-bis draft 8. Answer to WGLC

      

      


      

      

        

          

            

                
Stefan,

                
 

                
I have
                    finally reviewed your disposition of comments. I
                    have used draft 13.

                
 

                
I will
                    not address the comments in
                    sequence, but I will consider four categories:

                
 

                
Category
                      1) Some comments
                      which seem to be solved. Yes indeed,
                    they may be a few of them !

                
 

                
Category
                      2) Some comments
                      which might possibly be solved at
                    the WG level.

                
 

                
Category
                      3) Some comments
                      that I will address at the IETF last
                    call level, rather than the WG last call level,
                    since I disagree 

                    that it is “new ways to say the same thing” and it
                    is likely to be a waste of time for both of us to
                    argue again at the WG level 

                    (these comments are commented as “not broken”).

                
 

                
Category
                      4) Some typos and editorials found while
                    reading draft 13.

                
 

                
 

                
CATEGORY
                      1

                
 

                
Comment
                      4 (was editorial).

                
 

                
Comment
                      5.

                
 

                
Comment
                      6. 

                
 

                
Comment
                      19. Solved, since “unknown” seems
                    now to be also allowed for non-issued certificates 

                    (even if the OCSP responder is using a direct access
                    to the certificate database). See comment 8.

                
 

                
Comment
                      13: Acceptable, since the text uses “MAY”.

                
 

                
Comment
                      18. 

                
 

                
Comment
                      22.

                
 

                
Comment
                      23.

                
 

                
Comment
                      28.

                
 

                
CATEGORY
                      1

                
 

                
Comment
                      8: You have changed the meaning of the
                    revoked state in a way that is not what I requested.
                    

                
 

                
The
                    original text was:

                
 

                
   The
                      "revoked" state indicates that the certificate has
                      been revoked

                
   (either
                      permanantly or temporarily (on hold)).

                
 

                
The new
                    text is:

                
 

                
   The "revoked" state indicates that the certificate has been revoked

                
   either permanently or temporarily on hold (i.e. the revocation reason

                
   is certificateHold).

                
 

                
By
                    doing this, you do not allow any other case in the
                    future to have a temporary revocation: “temporarily
on

                      hold” 

                    is not the same as “temporarily

                      revoked”.

                
 

                
I
                    propose the following rewording: 

                
 

                
   The
                      "revoked" state indicates that the certificate has
                      been revoked 

                
   either permanently or temporarily (e.g. placed on hold).

                
 

                
The way
                    the text from draft 13 is now written seems to allow
                    using either “unknown” or “revoked” for
                    non-issued certificates. 

                    If this is the intent, then the good news is that
                    this does not come anymore into conflict with the
                    French rules which apply for 

                    the Administration since OCSP responders from CAs
                    used by the French Ministries having a direct access
                    to the database 

                    of issued certificates will be able to use “unknown”,
                    rather than “revoked” and
                    the reason code “onhold”.

                
 

                
However,

                    the current text is still mandating the use of Extended
                      Revoked Definition, but
                    the rational for its need it is very poor. 

                    As I have said on the PKIX list, the fact that the
                    revocation date is January 1rst, 1970 is fully
                    sufficient to know that we are in that 

                    very special case, and you have not provided a
                    rational to say the contrary.

                
 

                
So we
                    could get rid of it, … but the text from section
                    4.4.8 states:

                
 

                
   This extension MAY be present in other responses to signal that the

                
   responder implements the extended revoked definition in section 2.2.

                
 

                
I have
                    difficulties to understand what is really meant
                    there (“other responses” ?), since the text states:

                
 

                
   This extension indicates that the responder supports the extended

                
   definition of the "revoked" status to also include non-issued

                
   certificates according to section 2.2.

                
 

                
Since
                    both “unknown” and revoked” can be used, it would be
                    desirable to be able to include the same extension
                    in both cases, 

                    but in that case that extension should be renamed.

                
 

                
I would
                    propose to rename it: "non-issued
                      certificate”
                    which means that the associated CA has no record of
                    ever having issued 

                    a certificate with the certificate serial number in
                    the request (I still consider it as unnecessary in
                    the case of “revoked”, but it would be 

                    very useful in the case of “unknown”). Of course,
                    the text from section 4.4.8 would need to be
                    revised.

                
 

                
I
                    propose the following:

                
 

                
4.4.8  Non-issued certificate extension

                
 

                
   This extension MUST be included in the OCSP response when the OCSP 

                
   responder knows that the CA identified in the request has no record 

                
   of ever having issued a certificate with the certificate serial 

                
   number indicated in the request.

                
 

                
   Clients do not have to parse this extension in order to determine 

                
   the status of certificates in responses.

                
 

                
   This extension is identified by the object identifier id-pkix-ocsp-

                
   non-issued-cert.

                
 

                
     id-pkix-ocsp-non-issued-cert OBJECT IDENTIFIER ::= {id-pkix-ocsp 9}

                
 

                
   The value of the extension SHALL be NULL. This extension MUST NOT be

                
   marked critical.

                
 

                
Then
                    the text on page 8 would need to be rearranged.

                
 

                
The
                    current text is:

                
 

                
   This state MAY also be returned if the

                
   associated CA has no record of ever having issued a certificate with

                
   the certificate serial number in the request, using any current or

                
   previous issuing key (referred to as a "non-issued" certificate in

                
   this document).

                
 

                
   The "unknown" state indicates that the responder doesn't know about

                
   the certificate being requested.

                
 

                
   NOTE: The "revoked" state for known non-issued certificate serial

                
         numbers is allowed in order to reduce the risk of relying

                
         parties using CRLs as a fall back mechanism, which would be

                
         considerably higher if an "unknown" response was returned.

                
 

                
   When a responder responds revoked to a status request for a non-

                
   issued certificate, the responder MUST include the extended revoked

                
   definition response extension (section 4.4.8) in the response,

                
   indicating that the OCSP responder supports the extended definition

                
   of revoked state to also cover non-issued certificates. In addition,

                
   the SingleResponse related to this non-issued certificate;

                
 

                
    - MUST provide the revocation reason certificateHold (6),

                
 

                
    - MUST specify the revocationTime January 1, 1970, and;

                
 

                
    - MUST NOT include a CRL References extension (section 4.4.2) or any

                
      CRL Entry Extensions (section 4.4.5). 

                
 

                
Proposed

                    text for a replacement:

                
 

                
   The "unknown" state indicates that the responder doesn't know about

                
   the certificate being requested.

                
 

                
   If the OCSP responder knows that CA identified in the request has 

                
   no record of ever having issued a certificate with the certificate 

                
   serial number in the request, using any current or previous issuing 

                
   key (referred to as a "non-issued" certificate in this document), 

                
   the OCSP responder SHALL respond either “revoked “ or “unknown”.

                
 

                
   Note: The "revoked" state for known non-issued certificate serial 

                
   numbers is allowed in order to reduce the risk of relying parties 

                
   using CRLs as a fall back mechanism, which would be possible when 

                
   the "unknown" response is returned.

                
 

                
   When a responder responds revoked or unknown to a status request 

                
   for a non-issued certificate, the responder MUST include the 

                
   non-issued certificate extension (see section 4.4.8) in the 

                
   response. 

                
 

                
   When a responder responds revoked to a status request for a non-

                
   issued certificate, in addition, the responder:

                
 

                
    - MUST provide the revocation reason certificateHold (6),

                
 

                
    - MUST specify the revocationTime January 1, 1970, and;

                
 

                
    - MUST NOT include a CRL References extension (section 4.4.2) or any

                
      CRL Entry Extensions (section 4.4.5).

                
 

                
Finally,

                    the last bullet on page 4 should be reworded:

                
 

                
Current
                    text:

                
 

                
      o Section 4.4.8 specifies a new extension that indicates that the

                
         responder supports the extended use of the "revoked" response

                
         for non-issued certificates defined in section 2.2.

                
 

                
Proposed

                    replacement text:

                
 

                
      o  Section 4.4.8 specifies a new extension that indicates that 

                
         the OCSP responder knows that CA identified in the request 

                
         has no record of ever having issued a certificate with the 

                
         certificate serial number present in the request, as defined 

                
         in section 2.2.

                
 

                
Comment
                      9: Solved, if the comment above may be
                    solved.

                
 

                
Comment
                      20:  This

                    comment is preliminary classified by you as “not
                    broken”. However, since you asked: “If you don’t
                    replace 4.2.2.3,

                    then what really are you missing ?”, I will provide
                    you with an answer.

                
 

                
This is
                    the wrong way to state the question. Providing an
                    ASN.1 syntax as in 4.2.1 is not enough: the use of
                    every parameter 

                    MUST be explained using English words. So if you
                    explain the use of every parameter after the
                    description of the ASN.1 syntax 

                    in section 4.2.1. then section 4.2.2.3 is no more
                    needed and thus can be deleted.

                
 

                
The
                    answer to your question “what is really missing” is
                    a description of the use of every parameter listed
                    in the ASN.1 in section 4.2.1

                
 

                
Comment
                      21.

                
 

                
While I
                    can agree in general with the intent of the text, I
                    do not understand the first sentence of the Note
                    which speaks of “CA key rollover” 

                    and is copied below:

                
 

                
   Note: CA key rollover is not prohibited when issuing a certificate

                
         for an authorized responder for backwards compatibility with

                
         RFC 2560 [RFC2560]. That is, it is not prohibited to issue a

                
         certificate for an authorized responder using a different

                
         issuing key than the key used to issued the certificate being

                
         checked for revocation. However, such practice is strongly

                
         discouraged since clients are not required to recognize a

                
         responder with such certificate as an authorized responder.

                
 

                
I would
                    propose to delete it, since it does not add anything
                    and thus to have:

                
 

                
   Note: For backwards compatibility with RFC 2560 [RFC2560], it is 

                
         not prohibited to issue a certificate for an authorized 

                
         responder using a different issuing key than the key used to 

                
         issued the certificate being checked for revocation. 

                
         However, such practice is strongly discouraged since clients 

                
         are not required to recognize a responder with such 

                
         certificate as an authorized responder.

                
 

                
Comment
                      24: The ASN.1 module in annex B.1 is
                    still wrong, since it does not define NoCheck. 

                
 

                
Comment
                      26: You asked for explanations. Let me
                    provide you with an example when CRLs are being used
                    by the OCSP responder 

                    in the background. The OCSP responder needs to make
                    sure that the CRL it uses is valid. If it is simply
                    using published CRLs 

                    (i.e. no trusted link with the CA), it needs to make
                    sure that the CA which has issued the CRL has no
                    been revoked.

                
 

                
In France,
                    there is a root CA for the Administration. However,
                    the use of that root CA is optional. Thus a Ministry
                    may have its own root, 

                    but may also have its key certified by the root CA
                    of the Administration. The OCSP responder may use
                    the root CA of the Ministry, 

                    while a relying party may use the root CA of the
                    Administration (or the reverse) to validate the CRL
                    for the target certificate. 

                    Thus the revocation status will be different if the
                    certificate of the CA of the Ministry is revoked by
                    the root CA of the Administration.

                
 

                
CATEGORY
                      3

                
 

                
Comments 2, 3,
                    7, 10, 12, 14, 15, 16, 17, 25 and 27.

                
 

                
 

                
CATEGORY
                      4

                
 

                
Page 4.
                    The indentation of the bullets in section 1 is not
                    uniform. 

                    Bullets 1, 4, 5 and 9 have problems.

                
 

                
Page 4.
                    The fact that there is now an Annex B.2 dealing with
                    the 2008 ASN.1 syntax is missing. This should be
                    added.

                
 

                
Page
                    10. Change “Se
                      further section 4.2.2.2” into
                    “See

                      further section 4.2.2.2”

                    

                


                  Denis

                  

                
 

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

                      

                    

              

            

            

              
Denis,

              


              

              
Responding
                to your comments below.

              


              

              
However,
                one general remark to make recurring comments easier to
                understand.

              


              

              
The WG
                decided to adopt a minimalistic approach to updating RFC
                2560. That means that 

              
    
                
  1. We don't change anything from RFC 2560 unless it is
                  broken, or the industry clearly need clarifications in
                  order to avoid interoperability issues.
    2. 
                
  2. We retain the document structure of RFC 2560 as much
                  as possible to allow easy comparison of what the
                  changes are in comparison with RFC 2560.
    3. 
              

              


              

              
One can
                always think up more clever ways to write things out in
                words. But that also comes with a risk.

              
The
                current words has been around for a long time and we
                know from experience which words worked to produce
                working implementations, and which did not.

              
Introducing
                new ways to say the same thing may introduce new
                problems and people might disagree on what the new
                perfect wording should be. And this could go on forever.

              


              

              
So when my
                reply is "Not broken", then that is because the current
                wording does not have such problems that is merits a
                change.

              


              

              


              

              


              

              
                
From:
                   Denis Pinkas <denis.pinkas@bull.net>

                  Date:  Sunday,
                  January 20, 2013 5:12 PM

                  To:  Stefan
                  Santesson <stefan@aaa-sec.com>,

                  Stephen Kent <kent@bbn.com>

                  Cc:  pkix <pkix@ietf.org>

                  Subject:  Re:
                  [pkix] Review of 2560-bis draft 8. Answer to WGLC

                

                


                

                

                  

                    
 
                        
Please find 32 comments on
                          draft-ietf-pkix-rfc2560bis

                        
 

                        
1.
                            The document states:

                        
 <Cut away issue 1
                            regarding authorship etc, as it has been
                            responded to separately>

                      

                  

                

              
              


              

              
Responded
                to separately.

              


              

              
                

                  

                    

                        
 

                        
 

                        
2.
                            The current text from section 2 states:

                        
 

                        
2.  Protocol Overview

                        
 

                        
   In lieu of or as a supplement to checking against a periodic CRL, it

                        
   may be necessary to obtain timely information regarding the

                        
   revocation status of a certificate (cf. RFC5280], Section 3.3).

                        
   Examples include high-value funds transfer or large stock trades.

                        
 

                        
   The Online Certificate Status Protocol (OCSP) enables applications to

                        
   determine the (revocation) state of an identified certificate. OCSP

                        
   may be used to satisfy some of the operational requirements of

                        
   providing more timely revocation information than is possible with

                        
   CRLs and may also be used to obtain additional status information. 

                        
 

                        
This text is misleading because readers may think that OCPS necessarily provides “timely information”.

                        
 

                      

                  

                

              
              


              

              
"may" does
                not mean "necessarily".

              


              

              
                

                  

                    

                        
Proposed text replacement:

                        
 

                        
   The
                              Online Certificate Status Protocol (OCSP)
                              is a client-server 

                        
   protocol

                              which enables applications to obtain the
                              revocation status 

                        
   of
                              one or more certificates either "good",
                              "revoked", or "unknown".

                        
 

                        
   The
                              revocation status may be provided by the
                              server either using a 

                        
   real
                              time access to a database of issued
                              certificates, or using a 

                        
   batch
                              access to a database of issued
                              certificates, or using a 

                        
   real
                              time access to a database of revocation
                              statuses of issued 

                        
   certificates,

                              or using a batch access to a database of
                              revocation 

                        
   statuses
                              of issued certificates, or using CRLs, or
                              using a 

                        
   combination

                              of base CRLs and delta CRLs.

                        
 

                        
   In
                              the first case, it is possible to obtain
                              timely revocation status 

                        
   information,

                              whereas in the other cases, the freshness
                              of the 

                        
   revocation

                              status is not better than the mechanisms
                              it is based on.

                        
 

                        
 

                      

                  

                

              
              


              

              
Not broken

              


              

              
                

                  

                    

                        
3.
                            The current text from section 2 states:

                        
 

                        
   An OCSP client issues a status request to an OCSP responder and 

                        
   Suspends acceptance of the certificate in question until the 

                        
   responder provides a response.

                        
 

                        
   This protocol specifies the data that needs to be exchanged between

                        
   an application checking the status of a certificate and the server

                        
   providing that status.

                        
 

                        
Thus is insufficient for an overview. More details are needed to know what the document provides, 
in particular that the request may contain several requests for several certificates issued by different CAs. 
The possibility of using extensions should also be advertised.

                        
 

                        
Proposed text replacement:

                        
 

                        
  
                            When using OCSP, an OCSP client
                            issues a certificate revocation 

                        
  
                            status request to an OCSP responder for
                              one or more certificates 

                        
   issued
                              by the same CA or for one or more
                              certificates issued by 

                        
   different

                              CAs and then suspends acceptance of
                            the certificate(s) 

                        
  
                            in question until the responder
                            provides a response.

                        
 

                        
  
                            This document specifies the data that
                            needs to be exchanged between

                        
  
                            an application checking the status of
                            a certificate and the server

                        
  
                            providing that status.  

                        
 

                        
   OCSP
                              may also provide additional status
                              information using 

                        
   extensions.

                              

                        
 

                        
 

                      

                  

                

              
              


              

              
Not broken

              


              

              
                

                  

                    

                        
4.
                            Page 6. Editorial. Punctuation and a CR/LF
                            are missing.

                        
 

                        
The

                            text states:

                        
 

                        
   3. the request contains the information needed by the responder If

                        
      any one of the prior conditions are not met, the OCSP responder

                        
      produces an error message; otherwise, it returns a definitive

                        
      response.

                        
 

                        
It

                            should state:

                        
 

                        
   4. the request contains the information needed by the responder.

                        
 

                        
      If any one of the prior conditions are not met, the OCSP responder

                        
      produces an error message; otherwise, it returns a definitive

                        
      response.

                        
 

                        
 

                      

                  

                

              
              


              

              
Fixed in
                draft 10.

              


              

              
                

                  

                    

                        
5.
                            On page 7, the text states:

                        
 

                        
   All
                              definitive response messages SHALL be
                              digitally signed. The key

                        
   used
                              to sign the response MUST belong to one of
                              the following:

                        
 

                        
   -  the CA who issued the certificate in question

                        
   -  a Trusted Responder whose public key is trusted by the requester

                        
   -  a CA Designated Responder (Authorized Responder) who holds a

                        
      specially marked certificate issued directly by the CA, indicating

                        
      that the responder may issue OCSP responses for that CA.

                        
 

                        
The

                            paragraph is ambiguous on several aspects. 

                        
 

                        
Delegation


                            is addressed in at least three different
                            places, but with different terms and
                            conditions. 

                            If some one picks a sentence in one
                            paragraph rather than another, it will lead
                            to a different conclusion. 

                            RFCs are supposed to be clear.

                        
 

                        
On page 10, the current text
                            states in section
                            2.6
                              OCSP Signature Authority Delegation states:

                        
 

                        
   The key that signs a
                                certificate's status information need
                                not be the

                        
   same
                              key that signed the certificate. A certificate's issuer

                        
   explicitly

                              delegates OCSP signing authority by
                              issuing a certificate

                        
   containing
                              a unique value for extendedKeyUsage in the
                              OCSP signer's

                        
   certificate.

                              This certificate MUST be issued directly
                              to the

                        
   responder
                              by the cognizant CA.

                        
 

                        
On
                            page 16, there is a section 4.2.2.2 called “Authorized Responders” dealing with the same topic. 

                        
 

                        
Section

                            4.2.2.2 states:

                        
 

                        
   The key that signs a
                                certificate's status information need
                                not be the

                        
   same
                              key that signed the certificate. It is necessary however to

                        
   ensure
                              that the entity signing this information
                              is authorized to do

                        
   so.  Therefore,
                              a certificate's issuer MAY either sign the
                              OCSP

                        
   responses

                              itself or it MAY explicitly designate this
                              authority to

                        
   another

                              entity.  OCSP


                              signing delegation SHALL be designated by
                              the

                        
   inclusion
                              of id-kp-OCSPSigning in an
                              extendedKeyUsage certificate

                        
   extension

                              included in the OCSP response signer's
                              certificate. 
                              This

                        
   certificate

                              MUST be issued directly by the CA that
                              issued the

                        
   certificate

                              in question.

                        
 

                        
   The
                              CA SHOULD use the same issuing key to
                              issue a delegation

                        
   certificate

                              as was used to sign the certificate being
                              checked for

                        
   revocation.

                              Systems


                                relying on OCSP responses MUST recognize
                                a

                        
   delegation


                              certificate as being issued by the CA that
                              issued the

                        
   certificate


                              in question only if the delegation
                              certificate and the

                        
   certificate


                              being checked for revocation was signed by
                              the same key.

                        
 

                        
The

                            last sentence above in yellow is the key
                            sentence that is missing in the two other
                            sections.

                        
 

                        
Most implementations only support the case where the OCSP Responder receives an OCSP certificate that is signed by the same key 
that was used to sign the target certificate. They do not support the case where the OCSP Responder receives an OCSP certificate 
that is signed by a key that is different from the one that was used to sign the target certificate.

                        
 

                        
It
                            is inappropriate to have three sections
                            dealing with the same topic with a slightly
                            different meaning.

                        
 

                        
It
                            is proposed the following.

                        
 

                        
On
                            page 7, after:

                        
 

                        
   -  a CA Designated Responder (Authorized Responder) who holds a

                        
      specially marked certificate issued directly by the CA, indicating

                        
      that the responder may issue OCSP responses for that CA.

                        
 

                        
it
                            is proposed to add “(see section 4.2.2.2 for
                              further details)”,
                            so that the reader knows that more details
                            are provided later on.

                        
 

                        
Then we do not need two
                            sections to address delegation which start
                            with the same sentence:
                            

                          

                        


                            “The
                              key that signs a certificate's status
                              information need not be the same key that
                              signed the certificate”.

                        
 

                        
It
                            is thus proposed to delete section 2.6.

                        
 

                        
Section

                            4.2.2.2 will thus remain the single section
                            providing full details.

                        
 

                        
 

                      

                  

                

              
              


              

              
I have
                added references to section 4.2.2.2 in the quoted
                sections in 2.2 and 2.6.

              
(will be
                included in draft 11)

              


              

              


              

              
                

                  

                    

                        
6. Page 7, the text states:

                        
 

                        
   A definitive response message is composed of:

                        
 

                        
   -  version of the response syntax

                        
   -  name of the responder

                        
   -  responses for each of the certificates in a request

                        
   -  optional extensions

                        
   -  signature algorithm OID

                        
   -  signature computed across hash of the response

                        
 

                        
This

                            description does not fit with the ASN.1
                            syntax which is detailed later on, and in
                            particular:

                        
 

                        
   ResponseData ::= SEQUENCE {

                        
      version              [0] EXPLICIT Version DEFAULT v1,

                        
      responderID              ResponderID,

                        
      producedAt               GeneralizedTime,

                        
      responses                SEQUENCE OF SingleResponse,

                        
      responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

                        
 

                        
Proposed text replacement:

                        
 

                        
   A
                              definitive response message is composed
                              of:

                        
 

                        
   - a
                              response status and if there is no error,
                              the following:

                        
   -
                              the version of the response syntax,

                        
   - an
                              identifier of the OCSP server,

                        
   -
                              the time at which the response was
                              produced,

                        
   -
                              single responses for each of the target
                              certificates,

                        
   -
                              optional extensions,

                        
   -
                              the signature algorithm OID,

                        
   -
                              the signature computed across hash of the
                              response, and

                        
   -
                              optional certificates.

                        
 

                        
 

                      

                  

                

              
              


              

              
This is an
                overview section. We ought not try to duplicate the
                level of detail provided in the detailed protocol
                section.

              
A
                "definitive response" according to tho 2.1 is a response
                to an error-free request, so your first remark is
                redundant.

              


              

              
I have
                added a note about time to the current list, and changed
                "name" to identifier in bullet 2. 

              
(will be
                included in draft 11)

              


              

              
                

                  

                    

                        
7.
                            The text states on page 7:

                        
 

                        
   The
                              response for each of the certificates in a
                              request consists of

                        
 

                        
   -  target

                              certificate identifier

                        
   -  certificate

                              status value

                        
   -  response

                              validity interval

                        
   -  optional

                              extensions

                        
 

                        
However,


                            there are no explanations for the purpose of
                            these parameters and how they should be
                            processed.

                        
There

                            are also no explanations on how to process a
                            single response and how to verify that it is
                            its presence within the signed structure 

                            is valid or not valid. This is a major
                            deficiency of the current description of RC
                            2560 where there is no explanation on how to
                            validate 

                            a single response.

                        
 

                        
Text

                            proposal to be added after:

                        
 

                        
   The
                              purpose of the identifier of the OCSP
                              server is to allow OCSP 

                        
   clients
                              to find whether the definitive response
                              was signed by a CA 

                        
   or
                              by an OCSP Responder.

                        
 

                        
   The
                              identifier of the OCSP server SHOULD
                              either be the name or the 

                        
   key
                              from a CA, or the name or the key from a
                              OCSP Responder.

                        
 

                        
   Unless
                              there exist local rules (which are outside
                              the scope of this 

                        
   document)

                              for verifying that a single response is
                              correctly signed, 

                        
   the
                              following applies:

                        
 

                        
   When
                              the identifier matches with the name of
                              the CA which has issued 

                        
   the
                              target certificate or corresponds to the
                              key used to issue the 

                        
   target

                              certificate, then a single response is
                              correctly signed 

                        
   only
                              if the digital signature of the OCSP
                              response is valid using the 

                        
   key
                              used to sign the target certificate.

                        
 

                        
   When
                              the identifier does not match with the
                              name of the CA which has 

                        
   issued
                              the target certificate or does not
                              correspond to the key used 

                        
   to
                              issue the target certificate, then an
                              single response is correctly 

                        
   signed
                              only if :

                        
 

                        
         (a)

                              there exists in the response an OCSP
                              certificate issued by 

                        
             the

                              CA which has issued the target certificate
                              which is 

                        
             signed

                              by the same key as the one used to issue
                              the 

                        
             target


                              certificate, and

                        
 

                        
         (b)

                              the digital signature of the OCSP response
                              is valid using 

                        
             the


                              subjectPublicKey contained in this OCSP
                              certificate.

                        
 

                        
 

                      

                  

                

              
              


              

              
Not
                broken.

              
All of
                this is already covered by the document.

              


              

              
                

                  

                    

                        
8.
                            The text states on page 7:

                        
 

                        
   The
                            "revoked" state indicates that the
                            certificate has been revoked

                        
   (either

                              permanently or temporarily (on hold)). This

                            state MAY also be

                        
   returned
                            if the responder knows that the requested
                            certificate has

                        
   never
                              been issued during the history of the
                              associated CA using any

                        
   current
                            or previous issuing key. 

                        
 

                        
The

                            text is ambiguous because there are two
                            embedded parenthesis and it is unclear
                            whether the inner parenthesis means “i.e” or
                            “e.g”. 

                            This single sentence may let think that on
                            hold is the single case for temporarily
                            revocation. Since neither X.509 nor RFC 5280
                            address 

                            the case of a temporary revocation in the
                            context of an OCSP response (but only in the
                            context of CRLs), we are able to add another
                            case 

                            of temporary revocation which will only
                            apply in the context of OCSP.

                        
 

                        
The

                            above sentence using the terms “never been issued during the
                              history of the associated CA “does

                            not capture the fact 

                            that it could be issued in the future, hence
                            why using “not yet been
                              used” would

                            be more appropriate.

                        
 

                        
Finally,

                            it would have been more logical to use
                            “unknown”. So it is important to add a note
                            to explain why we have chosen that case for
                            “legacy clients”, 

                            otherwise the people who have not
                            participate to the exchanges will not
                            understand.

                        
 

                        
Proposed text replacement:

                        
 

                        
   The "revoked" state indicates that the certificate has been revoked,

                        
   either permanently or temporarily.

                        
 

                        
   A certificate may be temporarily revoked either because it is 

                        
   placed on hold (i.e. the revocation reason is certificateHold) or 

                        
   because the responder is able to know, using a positive list of 

                        
   issued certificates, that the serial number from the requested 

                        
   certificate has not yet been used by the CA to issue a certificate 

                        
   (i.e. the revocation reason is notIssuedOrIrregularlyIssued).

                        
 

                        
NOTE: The "revoked" state is used rather than the “unknown” state, to

                        
      make sure that relying parties that were conformant to RFC 2560

                        
      will not use CRLs as a fall back mechanism. 

                        
 

                      

                  

                

              
              


              

              
I removed
                the double parenthesis and adopted your clarification
                with regard to "on hold". 

              


              

              
The text
                in draft 10 has changed from what you have commented on.
                I believe that text is better.

              


              

              
You "Note"
                has problems.

              
    
                
  1. We do not prevent responders to respond "unknown" if
                  their assessment is that this is an appropriate
                  response, considering what they know about the
                  requested serial number. Thus the term "is used" is
                  misleading.
    2. 
                
  2. This mechanisms does not "make sure" that the
                  clients do anything. It's up to the discretion of the
                  relying party to decide what source of revocation
                  checking they rely on. This does however reduce the
                  risk of clients falling back to CRL:s
    3. 
                
  3. This mechanism is not just relevant to old clients,
                  but also to new one for the same reason.
    4. 
              

              


              

              
I have
                adopted a modified version of your Note:

              


              

              

                
   NOTE: The "revoked"
                    state for known non-issued certificate serial

                
         numbers is
                    allowed in order to reduce the risk of relying

                
         parties using
                    CRLs as a fall back mechanism, which would be

                
         considerably
                    higher if an "unknown" response was returned.

              

              


              

              


              

              


              

              
                

                  

                    

                        
 

                        
9.
                            The text states on page 8:

                        
 

                        
   When
                              a responder responds revoked to a status
                              request for a non-

                        
   issued

                              certificate, the responder MUST also;

                        
 

                        
    -
                              include the extended revoked definition
                              response extension

                        
      (section

                              4.8), indicating that the OCSP responder
                              supports the

                        
      extended

                              definition of revoked state to also cover
                              non-issued

                        
      certificates,

                        
 

                        
    -
                              provide the revocation reason
                              certificateHold (6), and;

                        
 

                        
    -
                              specify the revocation date January 1,
                              1970. 

                        
 

                        
As

                            already explained on the PKIX list, using
                            the revocation reason certificateHold
                            is not appropriate 

                            because it changes the meaning of
                            certificateHold. 

                        
 

                        
The

                            extended revoked definition response
                            extension is a means to signal that it not a
                            true certificate hold but a “not issued
                            certificate”. 

                            Legacy applications cannot take advantage of
                            it. 

                        
 

                        
Some

                            applications which handle non repudiation
                            enter a waiting state when the revocation
                            reason certificateHold is used thus 

                            it is not appropriate to overload the
                            meaning.

                        
 

                        
It
                            is possible to use another enumeration for
                            signalling that specific case:

                        
notIssuedOrIrregularlyIssued


                            (7).

                        
 

                        
Thus

                            for new applications it would be much better
                            to use notIssuedOrIrregularlyIssued (7) as
                            already proposed on the PKIX list.

                        
 

                        
The above sentence uses the text: 

                        
 

                        
“a status request for a non-issued certificate” 

                        
 

                        
whereas it would be more appropriate to state: 

                        
 

                        
“a status request for a serial number which has not been used by the CA or used irregularly to issue a certificate”.

                        
 

                        
Placing the ASN.1 description at such a place in the document is inappropriate since the ASN.1 structures have not yet been described. 
Thus only the functional aspects should be mentioned, but not the ASN.1 implications.

                        
 

                        
BTW, the description should follow the same order as the ASN.1. This is not the case. 

                        
 

                        
This text should be deleted from this section and the appropriate text should be added when the parameters of the response are described. 

                        
 

                        
The text proposed in the previous comment should be sufficient at this time of reading.

                        
 

                        
In addition, section 4.4.8  Extended


                              Revoked Definition should be
                            deleted.

                        
 

                        
 

                      

                  

                

              
              


              

              
The referred text has been updates in draft 09.

              


              

              
This has been discussed on the list and you have yet
                to convince the list of your new reason code.

              
I disagree as the risk of running into problems with
                the deployed base of application is hugely larger with
                introduction of a new reason code, rather than using
                certificateHold.

              
No application should be broken, since no application
                have business asking for non-issued cert serial numbers
                in the first place. Secondly, no application can assume
                that a certificateHold reason will be cleared any time
                soon.

              


              

              


              

              
                

                  

                    

                        
10.
                            The text states on page 8:

                        
 

                        
2.4  Semantics
                              of thisUpdate, nextUpdate and producedAt

                        
 

                        
This

                            section is misplaced. At this time of
                            reading, the reader does not know that
                            thisUpdate, nextUpdate and producedAt are
                            values 

                            used by the ASN.1 structures. It is
                            appropriate to describe what theses
                            parameters mean when the ASN.1 syntax is
                            described. 

                            The current ASN.1 syntax is very badly
                            described. One would expect that after every
                            ASN.1 structure description every parameter
                            is described. 

                            Unfortunately this is not the case. 

                            

                        
The

                            text from this section is not aligned with
                            the text that is present in section 4.2.2.1. 

                        
 

                        
In

                            particular, in section 2.4:

                        
 

                        
   If
                              nextUpdate is not set, the responder is
                              indicating that newer

                        
   revocation

                              information is available all the time.

                        
 

                        
While

                            in section 4.2.2.1:

                        
 

                        
   Responses

                              where the nextUpdate value is not set are
                              equivalent 

                        
   to a
                              CRL with no time for nextUpdate (see
                              Section 2.4).

                        
 

                        
It
                            is not appropriate to have two different
                            descriptions in two different places.

                        
 

                        
Delete

                            section 2.4. See comment number 19 for the
                            description of these parameters.

                      

                  

                

              
              


              

              
Not broken.

              
The current text segments fits well into a protocol
                overview section.

              


              

              
                

                  

                    

                        
 

                        
 

                        
11.
                            Section 2.5 is also misplaced. They use
                            values from the ASN.1 syntax which has not
                            yet been described. 

                            They should be moved or incorporated in the
                            document once the ASN.1 description has been
                            done.

                        
 

                      

                  

                

              
              


              

              
Not broken.

              


              

              
                

                  

                    

                        
 

                        
12.
                            Remainder: Section 2.6 should be deleted
                            (see comment number 5).

                        
 

                      

                  

                

              
              


              

              
Not broken.

              


              

              
                

                  

                    

                        
 

                        
13.
                            Section 2.7 states:

                        
 

                        
2.7  CA
                              Key Compromise

                        
 

                        
   If
                              an OCSP responder knows that a particular
                              CA's private key has

                        
   been
                              compromised, it MAY return the revoked
                              state for all

                        
   certificates

                              issued by that CA.

                        
 

                        
This

                            section is misleading and should be removed.
                            The reason is the following:

                        
 

                        
The

                            relying party must verify that the
                            singleResponse is signed by a responder
                            which is entitled to do so.

                        
 

                        
a)
                            If the CA key has been compromised and if
                            the response is signed by that CA key then
                            the singleResponse will be discarded 

                            when performing the certification path
                            validation whatever the content of the
                              response may be.

                        
 

                        
b)
                            If the CA key which has issued the OCSP
                            certificate has been compromised and if the
                            response is signed by the key present 

                            in the OCSP certificate then the
                            singleResponse will be discarded when
                            performing the certification path validation

                            whatever the content of the response may
                              be.

                        
 

                        
 

                        
Security


                            must be provided using the validation of the
                            certification path. Thus it does not matter
                            what the OCSP responder states.

                      

                  

                

              
              


              

              


              

              
Not broken.

              
An OCSP responder does not have to be chained to the
                broken CA. The relying party may have other trust
                configuration at choice.

              


              

              


              

              
                

                  

                    

                        


                        

                        
 

                        
14.
                            The text states on page 11:

                        
 

                        
3.2  Signed

                              Response Acceptance Requirements

                        
 

                        
   Prior
                              to accepting a signed response as valid,
                              OCSP clients SHALL

                        
   confirm

                              that:

                        
 

                        
   1.
                              The certificate identified in a received
                              response corresponds to

                        
      that

                              which was identified in the corresponding
                              request;

                        
 

                        
   2.
                              The signature on the response is valid;

                        
 

                        
   3.
                              The identity of the signer matches the
                              intended recipient of the

                        
      request.

                        
 

                        
   4.
                              The signer is currently authorized to sign
                              the response.

                        
 

                        
   5.
                              The time at which the status being
                              indicated is known to be

                        
      correct

                              (thisUpdate) is sufficiently recent.

                        
 

                        
   6.
                              When available, the time at or before
                              which newer information will

                        
      be

                              available about the status of the
                              certificate (nextUpdate) is

                        
      greater

                              than the current time.

                        
 

                        
This

                            section is misplaced since it uses terms
                            from the ASN.1 syntax and the protocol
                            description has not yet been made, 

                            since it is the next section 4. Its text is
                            not correct either. 

                        
 

                        
This

                            description does not take into account the
                            fact that a BasicOCSPResponse
                            may

                            contain one or several SingleResponses.
                            

                            In particular, the sentence “The signer
                              is currently authorized to sign the
                              response”
                          is misleading because a signer
                            

                            may be authorized to include some SingleResponses
                            but
                            not necessarily all of them. 

                        
 

                        
The

                            appropriate explanations should be done
                            after the description of the response, when
                            describing the processing of the response.

                        
 

                        
Delete

                            that section.

                        
 

                      

                  

                

              
              


              

              
Not broken.

              


              

              
                

                  

                    

                        
 

                        
15.
                            On page 12, after the ASN.1 description, the
                            only parameters which are described are: 

                        
hashAlgorithm,
                            issuerNameHash,


                              issuerKeyHash and serialNumber.

                        
 

                        
This is insufficient.  In
                            order to cover the full list of parameters,
                            the following text is proposed:

                        
 

                        
   requestorName

                              is optional and MAY be used by the server
                              for access 

                        
   control
                              and audit purposes.

                        
 

                        
   requestList

                              contains one or more single requests.

                        
 

                        
   requestExtensions

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

                        
 

                        
   reqCert

                              contains the identifier of a target
                              certificate.

                        
 

                        
   issuerNameHash

                              is the hash of the Issuer's distinguished
                              name.  The
                              

                        
   hash
                              shall be calculated over the DER encoding
                              of the issuer's name 

                        
   field
                              in the certificate being checked. 

                        
 

                        
   issuerKeyHash

                              is the hash of the Issuer's public key.  The
                              hash 

                        
   shall
                              be calculated over the value (excluding
                              tag and length) of the 

                        
   subject

                              public key field in the issuer's
                              certificate. 
                              The hash 

                        
   algorithm

                              used for both these hashes, is identified
                              in 

                        
   hashAlgorithm.

                              

                        
 

                        
      The
                              primary reason to use the hash of the CA's
                              public key in 

                        
      addition

                              to the hash of the CA's name, to identify
                              the issuer, 

                        
      is
                              that it is possible that two CAs may
                              choose to use the same 

                        
      name

                              (uniqueness in the Name is a
                              recommendation that cannot be 

                        
      enforced).


                              Two CAs will never, however, have the same
                              public key 

                        
      unless

                              the CAs either explicitly decided to share
                              their private 

                        
      key,
                              or the key of one of the CAs was
                              compromised.

                        
 

                        
   serialNumber

                              is the serial number of the certificate
                              for which 

                        
   status
                              is being requested.

                        
 

                        
   singleRequestExtensions


                              is OPTIONAL. 
                              Any specific extension is 

                        
   OPTIONAL.  The
                              critical flag SHOULD NOT be set for any of
                              them. 

                        
 

                        
   The
                              requestor MAY choose to sign the OCSP
                              request.  In
                              that case, the

                        
   signature
                              is computed over the tbsRequest structure.  If
                              the request

                        
   is
                              signed, the requestor SHALL specify its
                              name in the requestorName

                        
   field.  Also,
                              for signed requests, the requestor MAY
                              include

                        
   certificates

                              that help the OCSP responder verify the
                              requestor's

                        
   signature
                              in the certs field of Signature.

                        
 

                      

                  

                

              
              


              

              
Not broken.

              
The current text is short, but it is actually
                sufficient from the context of the ASN.1 definitions of
                the section. This is a detailed protocol section and the
                reader need to understand ASN.1 in any case to
                understand and implement the section.

              
The information about criticality is already covered
                in the extension section.

              


              

              


              

              
                

                  

                    

                        
 

                        
16. Section 4.1.2 is called: “Notes
                              on the Request Syntax”

                        
 

                        
The

                            first paragraph has been moved after the
                            description of issuerKeyHash
                            and

                            thus is no more needed.

                        
 

                        
The

                            second paragraph has been moved after the
                            description of requestExtensions.
                            

                            However, the sentence 

                            “ Unrecognized
                              extensions MUST be ignored (unless they
                              have the critical flag set and are not
                              understood)”
                            

                            has been deleted since it applies to the
                            OCSP responder and not to the OCSP client.
                            Thus it is no more needed.

                        
 

                        
The

                            third paragraph applies to signed requests.
                            However, it should belong to a section
                            dedicated on how clients should build OCPS
                            requests, 

                            which is currently missing. See the next
                            comment.

                        
 

                        
This

                            section should be deleted.

                        
 

                      

                  

                

              
              


              

              
Not broken.

              


              

              
                

                  

                    

                        
 

                        
17.
                            There should be a new section called: “Requirements for OCSP
                              clients”. 

                        
 

                        
It
                            is important first to re-advertise that the
                            request may be about several certificates. 

                            Thus it is important to describe the process
                            for building a request, which is currently
                            missing.

                        
 

                        
   An
                              OCSP request allows getting in the same
                              response the revocation 

                        
   status
                              of one or more certificates.  In
                              order to request the 

                        
   status
                              of one or more certificates in a single
                              request, OCSP 

                        
   clients

                              SHALL follow the following rules :

                        
 

                        
   For
                              each candidate certificate, OCSP clients
                              SHALL verify 

                        
   whether

                              there exists a locally defined rule for
                              the certificate in 

                        
   question

                              which indicates the URI where the OCSP
                              responder is 

                        
   located.  If
                              this rule exists, it SHALL be followed. 

                        
 

                        
   Otherwise,

                              OCSP clients SHALL determine whether the
                              candidate 

                        
   certificate

                              contains an AIA extension with an
                              accessMethod which 

                        
   contains
                              the id-ad-ocsp OID.  If it
                              is the case, the accessLocation 

                        
   contains
                              a uniformResourceIdentifier (URI) which
                              indicates the 

                        
   location
                              of the OCSP server for that certificate. 

                        
 

                        
   Certificates

                              that contain the same URI MAY be grouped
                              in a single 

                        
   request.

                        
 

                        
Note:  For
                              each candidate certificate, when
                              performing the path 

                        
       validation


                              algorithm, the OCSP client SHOULD verify
                              that the 

                        
       current

                              time is within the validity period of the
                              target 

                        
       certificate.  Certificates

                              which are outside their validity 

                        
       period

                              SHOULD NOT be included in the request.

                        
 

                        
   The
                              requestor MAY choose to sign the OCSP
                              request. In that case, the

                        
   signature
                              is computed over the tbsRequest structure.
                              If the request

                        
   is
                              signed, the requestor SHALL specify its
                              name in the requestorName

                        
   field.
                              Also, for signed requests, the requestor
                              MAY include

                        
   certificates

                              that help the OCSP responder verify the
                              requestor's

                        
   signature
                              in the certs field of Signature.

                        
 

                      

                  

                

              
              


              

              
Not broken.

              


              

              
Your text may provide guidance that could be useful
                to some implementers, but is completely beyond this
                document and further, not generally applicable or true.

              
As an example, an organisation may setup an in house
                locally configured OCSP responder that responds to all
                certificates "out there" that is relevant to that
                organisation.

              
Such clients would just blindly send OCSP requests to
                their local responder, disregarding any information in
                the cert.

              
It's totally beyond this spec to have an opinion
                about this.

              


              

              


              

              
                

                  

                    

                        
 

                        
18.
                            The text states on page 14:

                        
 

                        
   The
                              responder MAY include certificates in the

                        
   certs
                              field of BasicOCSPResponse that help the
                              OCSP client verify the

                        
   responder's

                              signature. If no certificates are included
                              then certs

                        
   SHOULD
                              be absent.

                        
 

                        
While

                            this sentence is true, it is not sufficient.
                            In order to allow verifying every SingleResponse,
                            

                            it is important to include the relevant
                            certificates which are pertinent to every SingleResponse.

                        
 

                        
Proposed


                            full text replacement:

                        
 

                        
   The
                            responder MAY include certificates in the
                            certs field of 

                        
   BasicOCSPResponse


                            that help the OCSP client verify the
                            responder's 

                        
   signature.

                        
 

                        
   For
                              every SingleResponse where the responder
                              is not a CA, the 

                        
   responder

                              SHALL include the relevant OCSP
                              certificate in the certs 

                        
   field
                              of BasicOCSPResponse in order to allow the
                              OCSP client 

                        
   verifying

                              the responder was entitled to include that
                              SingleResponse 

                        
   in
                              the signed BasicOCSPResponse.

                        
 

                        
   If no certificates are included
                            then certs SHOULD be absent.

                        
 

                      

                  

                

              
              


              

              
Not broken.

              


              

              
This requirement would break backwards compatibility
                with RFC 2560.

              
Further this would not be needed for a locally
                configured responder.

              


              

              
                

                  

                    

                        
 

                        
19.
                            Page 15. The ASN.1 syntax should be changed
                            in order to be able to use the enumeration
                            case 7 that is not used for CRLs. 

                            This leads to the following change:

                        
 

                        
Current

                            text:

                        
 

                        
       revocationReason    [0]     EXPLICIT

                              CRLReason OPTIONAL }

                        
 

                        
Proposed


                            text change:

                        
 

                        
Current

                            text:

                        
 

                        
       revocationReason

                                 [0]     EXPLICIT

                              RevocationReason OPTIONAL }

                        
 

                        
RevocationReason
                              ::= ENUMERATED {

                        
        unspecified                    (0),

                        
        keyCompromise                  (1),

                        
        cACompromise                   (2),

                        
        affiliationChanged             (3),

                        
        superseded                     (4),

                        
        cessationOfOperation           (5),

                        
        certificateHold                (6),

                        
        notIssuedOrIrregularlyIssued


                                (7),

                        
        removeFromCRL                  (8),

                        
        privilegeWithdrawn             (9),

                        
        aACompromise                  (10) }

                        
 

                      

                  

                

              
              


              

              
Not broken.

              


              

              
You have to convince the list about your new reason
                code.

              


              

              
                

                  

                    

                        
 

                        
20. Page 15. After the ASN.1
                            syntax, there is no description of every
                            parameter, neither on its use 

                            (except a few words in section
                            4.2.2.1
                              Time about
                            thisUpdate,

                              nextUpdate and producedAt).

                        
 

                        
Every parameter needs to be
                            described and explained.

                        
 

                        
   responderID

                              indicates either the name or the key from
                              a CA, or the 

                        
   name
                              or the key from a OCSP Responder.

                        
 

                        
   producedAt

                              indicates the time at which this response
                              was signed.

                        
 

                        
   responses

                              contains one or more single responses.

                        
 

                        
   responseExtensions

                              is OPTIONAL. 
                              Any specific extension is OPTIONAL.

                        
   The
                              critical flag may or may not be set.

                        
 

                        
   certID
                              is usually a copy of the same field which
                              was placed in the 

                        
   request,
                              but for OCSP responders which pre-produce
                              signed responses 

                        
   certID
                              may be the identifier of a target
                              certificate that was not 

                        
   present
                              in the request (see the end of section
                              4.2).

                        
 

                        
   certStatus

                              indicates the status of the certificate:
                              either good, 

                        
   revoked
                              or unknown.

                        
 

                        
   thisUpdate

                              indicates the time at which the status
                              being indicated 

                        
   is
                              known to be correct.

                        
 

                        
   nextUpdate

                              indicates the time at or before which
                              newer information 

                        
   will
                              be available about the status of the
                              certificate. 
                              If 

                        
   nextUpdate

                              is not set, the server is indicating that
                              newer 

                        
   revocation

                              information is available all the time. 

                        
 

                        
   If
                              nextUpdate is set, it often corresponds to
                              the {thisUpdate, 

                        
   nextUpdate}

                              interval in CRLs.  Responses
                              whose nextUpdate value is 

                        
   earlier
                              than the local UTC time value SHOULD be
                              considered 

                        
   unreliable.  Responses

                              whose thisUpdate time is later than the
                              local 

                        
   UTC
                              time SHOULD be considered unreliable.

                        
 

                        
   singleExtensions

                              is OPTIONAL. 
                              Any specific extension is OPTIONAL.

                        
   The
                              critical flag SHOULD NOT be set for any of
                              them.

                        
 

                        
   revocationTime


                              indicates the time at which the
                              certificate was 

                        
   revoked.

                        
 

                        
   revocationReason

                              is OPTIONAL.  It
                              includes all the cases that are 

                        
   present
                              in CRLReason used for CRLs and an
                              additional case 7 which is

                        
   not
                              used for CRLs.  Case
                              7 is called notIssuedOrIrregularlyIssued.
                              

                        
 

                        
      -
                              "notIssued" corresponds to the case where
                              the certificate 

                        
         serial

                              number that was sent was erroneous and has
                              not yet 

                        
         been

                              used by the CA at the time of the query,

                        
 

                        
      -
                              "irregularlyIssued" corresponds to the
                              case where the 

                        
         certificate


                              serial number that was sent really exists
                              in a 

                        
         certificate

                              that is correctly signed, but to its
                              knowledge 

                        
         the
                              CA has not issued a certificate with such
                              a serial 

                        
         number.

                               As
                              an example, it may have been issued by the
                              CA 

                        
         because

                              the RA was compromised. 

                        
 

                        
   When a responder responds revoked to a status request for which it 

                        
   knows that the serial number has not been used by the CA or has 

                        
   been irregularly used irregularly to issue a certificate, then 

                        
   in RevokedInfo the responder MUST:

                        
 

                        
      - specify the revocationTime :  January 1, 1970,

                        
      - provide the revocationReason: notIssuedOrIrregularlyIssued (7).

                        
 

                        
   and in SingleResponse the responder MUST NOT include the nextUpdate.

                        
 

                        
   The
                              response MUST include a SingleResponse for
                              each certificate in

                        
   the
                              request and SHOULD NOT include any
                              additional SingleResponse

                        
   elements.  However,

                              there is one exception: 

                        
 

                        
      OCSP

                              responders MAY pre-produce signed
                              responses specifying the 

                        
      status
                              of certificates at a specified time.  The
                              time at which 

                        
      the

                              status was known to be correct SHALL be
                              reflected in the 

                        
      thisUpdate

                              field of the response. 

                        
 

                        
      OCSP

                              responders that pre-generate status
                              responses MAY return 

                        
      responses

                              that include additional SingleResponse
                              elements if

                        
      necessary

                              to improve response pre-generation
                              performance or cache

                        
      efficiency

                              (as permitted in [RFC5019]).

                        
 

                        
Since the text above provides
                            all the explanations at the level of the
                            ASN.1 parameters, the general text 

                            from section 4.2.2.3 Basic Response is no more need and should be
                            deleted.

                        
 

                      

                  

                

              
              


              

              
Preliminary I would say "not broken".

              
If you don't replace 4.2.2.3, then what really are
                you missing?

              


              

              
                

                  

                    

                        
 

                        
21.
                            0n page 16, there is a section 4.2.2.2 called “Authorized
                              Responders”

                        
 

                        
Section

                            4.2.2.2 states:

                        
 

                        
   (…)

                        
   This
                              certificate MUST be issued directly by the
                              CA that issued the

                        
   certificate

                              in question.

                        
 

                        
   The
                              CA SHOULD use the same issuing key to
                              issue a delegation

                        
   certificate

                              as was used to sign the certificate being
                              checked for

                        
   revocation.

                              Systems relying on OCSP responses MUST
                              recognize a

                        
   delegation

                              certificate as being issued by the CA that
                              issued the

                        
   certificate

                              in question only if the delegation
                              certificate and the

                        
   certificate

                              being checked for revocation was signed by
                              the same key.

                        
 

                        
This

                            section would need to reformatted to address
                            CA requirements first and then OCSP
                            responder requirements:

                        
 

                        
   (…)

                        
   This
                              certificate MUST be issued directly by the
                              CA that issued the

                        
   certificate

                              in question. 
                              The CA SHOULD use the same issuing
                              key to 

                        
   issue
                              a delegation certificate as was used to
                              sign the certificate 

                        
   being

                              checked for revocation. 

                        
 

                        
   Systems

                              relying on OCSP responses MUST be able
                                to recognize a 

                        
   delegation

                              certificate as being issued by the CA that
                              issued the 

                        
   certificate

                              in question if the delegation certificate
                              and 

                        
   the
                              certificate being checked were
                              signed by the same key.

                        
 

                      

                  

                

              
              


              

              
I disagree. The CA is actually free to do anything,
                but cannot expect the client to recognise the responder
                as authorised unless the same private key is used.

              
The current text places the requirement where they
                belong.

              


              

              
                

                  

                    

                        
 

                        
22.
                            On page 17, the text states:

                        
 

                        
   They
                              MUST reject the

                        
   response
                              if the certificate required to validate
                              the signature on the

                        
   response

                              fails to meet at least one of the
                              following criteria:

                        
 

                        
This is ambiguous. It is
                            inappropriate to have a negative statement
                            like “They
                              MUST reject”. 

                            The sentence should be turned in the
                            positive form “They SHALL accept”
                            

                        
 

                        
Since

                            the ASN.1 syntax has now be described, it is
                            possible to be more specific.

                        
 

                        
The

                            first occurrence of the word “response”
                            should be changed into “singleResponse”,
                            while the second occurrence 

                            of the word “response” should be changed
                            into “ResponseData”

                        
 

                        
Proposed


                            text replacement:

                        
 

                        
   They
                              SHALL accept a singleResponse if the
                              certificate required to 

                        
   validate
                              the signature placed on the ResponseData
                              meets one of the 

                        
   following

                              criteria:

                      

                  

                

              
              


              

              


              

              
No, this change is not backwards compatible.

              
So state the requirements for rejection is not
                equivalent to stating requirements for acceptance.

              
There may be other locally configured reasons to
                reject in addition to those listed in the standard.

              


              

              


              

              
                

                  

                    

                        
 

                        
 

                        
23.
                            On page 17, the text states:

                        
 

                        
   3.
                              Includes a value of id-kp-OCSPSigning in
                              an ExtendedKeyUsage

                        
   extension

                              and is issued by the CA that issued the
                              certificate in

                        
   question
                              as stated above."

                        
 

                        
In

                            order to be crystal clear, it is proposed to
                            change the wording in the following way:

                        
 

                        
   3.
                              Includes a value of id-kp-OCSPSigning in
                              an ExtendedKeyUsage

                        
   extension

                              and was signed by the CA using the same
                              key that used 

                        
   to
                              issue the certificate in question.

                        
 

                      

                  

                

              
              


              

              
No, issuing with another key is not prohibited, and
                may be accepted by some clients as an authorised
                responder.

              


              

              
                

                  

                    

                        
 

                        
24.
                            On page 17, the text states:

                        
 

                        
   This
                              SHOULD be a non-critical extension. The
                              value of the extension 

                        
   SHALL
                              be NULL.

                        
 

                        
The ASN.1 syntax is missing.
                            Add: 

                        
 

                        
   NoCheck
                              ::= NULL

                        
 

                        
 

                      

                  

                

              
              


              

              
Moving this to a separate discussion.

              
I'm not sure what the preferred way to describe this
                is.

              


              

              


              

              
                

                  

                    

                        
25.
                            Remainder: On page 18, the general text from
                            section 4.2.2.3
                              Basic Response is no more needed and 

                            should be deleted. See comment 20.

                        
 

                        
 

                      

                  

                

              
              


              

              
Not broken.

              


              

              
                

                  

                    

                        
26.
                            On page 24, text should be added to the
                            Security consideration section:

                        
 

                        
Different results when using
                              OCSP and CRLs

                        
 

                        
   OCSP
                              clients or verifiers must build and verify
                              a certification path 

                        
   for
                              each target certificate up to a trusted
                              root.  When
                              an OCSP 

                        
   Responder
                              is using published CRLs, it must also
                              build and verify a 

                        
   certification

                              path for the CRLs it uses up to a trusted
                              root.

                        
 

                        
   However,
                              it should be realized that the root used
                              by an OCSP 

                        
   Responder
                              to verified these CRLs is not necessarily
                              the same as the 

                        
   one
                              that would be used by the OCSP client, if
                              it were going to verify 

                        
   the
                              CRLs itself. 
                              Hence the revocation status may not
                              be identical 

                        
   in
                              both cases.

                        
 

                        
 

                      

                  

                

              
              


              

              
I don't understand this one.

              


              

              
                

                  

                    

                        
27.
                            On page 24, text should be added to the
                            Security consideration section:

                        
 

                        
Denial of service attack
                              using a flood of queries

                        
 

                        
   A
                              denial of service vulnerability is evident
                              with respect to a flood 

                        
   of
                              queries.  The

                              production of a cryptographic signature 

                        
   significantly

                              affects response generation cycle time,
                              thereby 

                        
   exacerbating

                              the situation. 

                        
 

                        
   The
                              flood of queries may either come from a
                              flood attack or from the 

                        
   fact
                              that there are too many certificates
                              supported by the same OCSP 

                        
   responder.  In
                              the later case, the number of queries can
                              be 

                        
   reduced
                              by using a technique similar to the
                              splitting of CRLs: 

                        
 

                        
      When
                              a block of certificates have been issued
                              with the same 

                        
      accessLocation

                              in the AIA extension field of these
                              certificates, 

                        
      then
                              the accessLocation should be changed.  In
                              this way, a given 

                        
      OCSP

                              server will only be responsible for a
                              block of certificates.

                        
 

                      

                  

                

              
              


              

              
If the security considerations section is talking
                about splitting OCSP responders in this way, then the
                document itself need to introduce the subject.

              
I would suggest that it is beyond this update to do
                so.

              


              

              
                

                  

                    

                        
 

                        
28.
                            On page 31, the text states.

                        
 

                        
   An
                              alternative to this module that conforms
                              to the 2002 version of 

                        
   ASN.1
                              may be found in Section 4 of [RFC5912]. 

                        
 

                        
RFC

                            5912 omits to define the nocheck extension.
                            Thus it is inappropriate to refer to RFC
                            5912. 

                        
 

                        
The

                            corrected module should be defined in this
                            new draft. 

                            A corrected module is provided in draft-pinkas-rfc2560bis-03.

                        
 

                      

                  

                

              
              


              

              
Will move this (as stated above) to a separate
                discussion.

              


              

              
                

                  

                    

                        
 

                        
29.
                            Different topics are not covered by the
                            document. These topics are important. 

                            The following comments propose text to be
                            placed in annexes. Three annexes are being
                            proposed.

                        
 

                        
Note:

                            The texts are extracted from draft-pinkas-rfc2560bis-03.

                        
 

                        
 

                      

                  

                

              
              


              

              
Not broken.

              
Each such amendment need to be thoroughly reviewed
                and motivated.

              


              

              


              

              
                

                  

                    

                        
30.
                            First annex being proposed. This annex is
                            important, because key rollover is not
                            addressed in the draft.

                        
 

                        
KEY ROLLOVER

                        
 

                        
1. CA that directly supports
                              an OCSP service

                        
 

                        
   When
                              a CA that directly supports an OCSP
                              service performs a key 

                        
   rollover:

                        
 

                        
   -
                              for certificates issued under the old key,
                              the CA SHALL continue 

                        
     to
                              sign the revocation status of OCSP
                              responses with that old key 

                        
     at
                              least until all these certificates are
                              expired, and

                        
 

                        
   -
                              for certificates issued under the new key,
                              the CA SHALL change the 

                        
     accessLocation

                              in the AIA extension field of these
                              certificates 

                        
     and
                              sign the revocation status of OCSP
                              responses with that new key 

                        
     at
                              least until all these certificates are
                              expired.

                        
 

                        
   Note:
                              The change in accessLocation is necessary
                              when the CA rekeys 

                        
         to

                              meet the following constraints imposed by
                              this standard: 

                        
 

                        
            1)

                              a BasicOCSPResponse can only be signed
                              using a single 

                        
              
                              private key; 

                        
 

                        
            2)

                              the response must be signed using the same
                              CA key that 

                        
               was
                              used to sign the certificate in question;
                              and

                        
 

                        
            3)

                              the OCSP response needs to cover all the
                              certificates 

                        
              
                              queried in the OCSP request.

                        
 

                        
2. CA that uses OCSP
                              responders

                        
 

                        
   When
                              a CA that uses OCSP Responders performs a
                              key rollover, then 

                        
   it
                              MUST either designate a new OCSP Responder
                              or keep the current 

                        
   OCSP
                              Responder(s).

                        
 

                        
   If
                              the CA designates a new OCSP Responder,
                              then it SHALL change the 

                        
   accessLocation

                              in the AIA extension field for the newly
                              issued 

                        
   certificates

                              and issue an OCSP certificate to the new
                              OCSP Responder 

                        
   using
                              its new key.

                        
 

                        
   If
                              the CA keeps the same OCSP Responder(s),
                              then it SHALL continue 

                        
   to
                              use the same accessLocation(s) in the AIA
                              extension field for the 

                        
   newly
                              issued certificates and issue an OCSP
                              certificate to the 

                        
   appropriate

                              OCSP Responder(s) using its new key.

                        
 

                        
   Note:
                              The CA may need to continue issuing
                              certificates to the OCSP 

                        
   Responder(s)

                              using the old CA key until all the
                              certificates issued 

                        
   under
                              the CA' old key for which the OCSP
                              Responder(s) are 

                        
   authoritative

                              have expired.

                        
 

                        
3. OCSP Responder key
                              rollover

                        
 

                        
   When
                              an OCSP Responder performs a key rollover
                              (asynchronously from 

                        
   a CA
                              key rollover), then each CA which has
                              designated an OCSP 

                        
   Responder

                              SHALL issue a new certificate for that
                              OCSP Responder and 

                        
   for
                              each of its issuing keys which meets the
                              following property: 

                        
 

                        
      -
                              the issuing key has been used to sign at
                              least one certificate 

                        
        which

                              contains an AIA extension designating that
                              OCSP Responder 

                        
        and

                              that certificate is not yet expired.

                        
 

                        
   An
                              OCSP Responder key rollover does not
                              affect the values of the 

                        
   URIs
                              that are placed in the accessLocation
                              field from the target 

                        
   certificates.  One
                              or more OCSP Responder MAY respond to an
                              OCSP 

                        
   request

                              addressed at a given URI picked from the
                              accessLocation 

                        
   field
                              from a target certificate.  Each
                              OCSP Responder MAY use a 

                        
   different

                              signing key, as long as it got an OCSP
                              certificate 

                        
   appropriate

                              for that signing key and for the target
                              certificate. 

                        
 

                        
 

                        
31.
                            Second annex being proposed. This annex is
                            important because it describes the
                            validation of an OCSP response in the past 

                            which is of a particular importance when
                            validating electronic signatures.

                        
 

                        
Response processing by an
                              OCSP client

                        
 

                        
   OCSP
                              responses can be verified at the current
                              time by an OCSP client 

                        
   when
                              receiving a response, whereas old
                              responses can be verified at 

                        
   a
                              time in the past by a verifier.  The
                              algorithm below addresses 

                        
   both
                              cases.

                        
 

                        
   Prior
                              to processing a basic response, OCSP
                              clients MUST determine 

                        
   the
                              checking time, which may be either the
                              current time or a time 

                        
   in
                              the past.

                        
 

                        
   OCSP
                              clients or verifiers SHALL check if the
                              response contains 

                        
   responseExtensions.

                              If such an extension is found and is
                              recognized, 

                        
   it
                              MUST be processed.  If
                              such a critical extension is found and 

                        
   is
                              not recognized, the whole OCSP response
                              MUST be considered as 

                        
   invalid.

                        
 

                        
   If
                              the checking time is the current time, and
                              if a nonce extension 

                        
   has
                              been used in the request and is recognized
                              (see section 4.5.1), 

                        
   OCSP
                              clients MUST check whether the same nonce
                              is present in the 

                        
   response.  If
                              the nonce is not present or is different,
                              then the 

                        
   OCSP
                              response MUST be discarded.

                        
 

                        
   Only
                              the single response(s) which are/is of
                              interest SHALL be 

                        
   checked.

                        
 

                        
STEP 1

                        
 

                        
   OCSP
                              clients or verifiers SHALL verify that the
                              certificate 

                        
   identified

                              in a single response is of interest.  Otherwise,

                              proceed 

                        
   to
                              step 3.

                        
 

                        
   If
                              the certificate status included in a
                              single certificate response 

                        
   is
                              "unknown", then the revocation status of
                              that certificate is 

                        
   "unknown",

                              and proceed to step 3.

                        
 

                        
   If
                              the certificate status from the single
                              certificate response is 

                        
   either

                              "good" or "revoked", OCSP clients or
                              verifiers SHALL check 

                        
   that
                              the checking time is within the validity
                              period of the target 

                        
   certificate.  If it
                              is not the case, then the revocation
                              status of 

                        
   that
                              certificate is "unknown" and proceed to
                              step 3.

                        
 

                        
   If
                              the checking time is the current time, and
                              if a nonce has been 

                        
   used
                              in the request, then proceed to step 2.

                        
 

                        
   If
                              the checking time is the current time, and
                              if no nonce has been 

                        
   used
                              in the request, OCSP clients MUST check
                              that the producedAt

                        
   field
                              is within a time window that is "close
                              enough" to the current 

                        
   time.
                              

                        
 

                        
   Note:
                              the notion of "close enough" is a local
                              matter.  It
                              can be set 

                        
         to
                              a few minutes to allow for small UTC time
                              differences 

                        
         between

                              the client and the server or to a few
                              hours in case 

                        
         the

                              server is producing pre-computed
                              responses.

                        
 

                        
   If
                              the checking time is a time in the past,
                              verifiers MUST check 

                        
   that
                              the producedAt field is in accordance with
                              the verification 

                        
   rules
                              (e.g. close and/or after the date of a
                              time-stamp token).

                        
 

                        
   In
                              addition, if the nextUpdate field is
                              present, OCSP clients MUST 

                        
   check
                              that the time which is indicated is
                              greater than the checking 

                        
   time,

                              otherwise the single response MUST be
                              discarded.

                        
 

                        
   If
                              checks are successful, then OCSP clients
                              MUST process the 

                        
   singleExtensions


                              field, if it is present. 

                        
 

                        
   If
                              the criticality flag is set and the
                              extension is not understood, 

                        
   then
                              the status of the certificate shall be
                              "unknown" and proceed to 

                        
   step
                              3.  Otherwise,

                              proceed to step 2. 

                        
 

                        
   If
                              the extension is understood, then the
                              extension MUST be 

                        
   processed.  According
                              to its content proceed either to step 2 or
                              to 

                        
   step
                              3. 

                        
 

                        
STEP 2

                        
 

                        
   OCSP
                              clients or verifiers MUST build and verify
                              a certification path 

                        
   for
                              that certificate up to a trusted root, so
                              that they have the 

                        
   knowledge
                              of the CA public key value that was used
                              to sign the 

                        
   target

                              certificate. 
                              The revocation status of each
                              certificate of 

                        
   that
                              certification path (except the target
                              certificate) SHALL be 

                        
   checked.

                        
 

                        
   If
                              no path can be built or if one of the
                              certificates of the path is 

                        
   revoked,

                              then the revocation status of that
                              certificate is "unknown", 

                        
   and
                              proceed to step 3. 

                        
 

                        
   If
                              the certification path (except the target
                              certificate) is valid, 

                        
   then
                              two cases need to be considered:

                        
 

                        
   a)
                              If the responderID matches with the name
                              or the key from the CA 

                        
      which
                              has issued the target certificate, then
                              check whether the 

                        
      OCSP

                              response is signed by the same key that
                              was used to sign 

                        
      the

                              target certificate.

                        
 

                        
             If

                              it is the case, then the revocation status
                              of that 

                        
             certificate


                              as indicated in the certStatus field is 

                        
             accepted

                              and proceed to step 3.

                        
 

                        
             If

                              it is not the case, then the revocation
                              status of that 

                        
             certificate


                              is "unknown" and proceed to step 3.

                        
 

                        
   b)
                              If the responderID does not match with the
                              name or the key from 

                        
      the
                              CA which has issued the target
                              certificate, then it indicates 

                        
      the
                              name or the key from an OCSP Responder.  Check
                              whether there 

                        
      exists
                              a local rule which applies to this target
                              certificate to 

                        
      verify

                              that the signature of the
                              BasicOCSPResponse is valid for 

                        
      that

                              single response.  If
                              this rule exists, it SHALL be followed. 

                        
 

                        
      Otherwise

                              check whether there is an OCSP certificate
                              (i.e. which 

                        
      has
                              both the ocspSigning OID in the extended
                              key usage extension 

                        
      and
                              the digitalSignature bit in the key usage
                              extension) signed 

                        
      by
                              the same key that was used to sign the
                              target certificate. 

                        
      This

                              certificate MUST be present in the certs
                              field from the 

                        
      BasicOCSPResponse.


                              

                        
 

                        
          If

                              such certificate is not found or is
                              invalid, then the 

                        
          revocation


                              status of that certificate is "unknown"
                              and 

                        
          proceed

                              to step 3.

                        
 

                        
          If

                              such certificate exists and if the
                              checking time is 

                        
          within

                              the validity period of this certificate,
                              then it MUST 

                        
          be

                              verified whether the OCSP response can be
                              verified using 

                        
          the

                              public key that is present in the OCSP
                              Certificate. 

                        
 

                        
             If

                              it is not the case, then the revocation
                              status of that 

                        
             certificate


                              is "unknown" and proceed to step 3.

                        
 

                        
             If

                              it is the case, then it MUST be verified
                              that the OCSP 

                        
             Certificate


                              has not been revoked.

                        
 

                        
     If
                              one of these conditions is met, then the
                              status for the target 

                        
     certificate

                              as indicated in the certStatus field is
                              accepted, 

                        
     otherwise

                              the revocation status is "unknown".

                        
 

                        
STEP 3

                        
 

                        
   If
                              there exists another single certificate
                              status response for a 

                        
   target

                              certificate that is of interest, then
                              proceed to step 1. 

                        
   Otherwise

                              the basic response is now processed.

                        
 

                        
 

                        
32.
                            Third annex being proposed. This annex is
                            important because it provides guidance on
                            how to build an OCSP responder in the three
                            cases. 

                            Many text portions are similar, but three
                            full texts are provided in order to provide
                            a better clarity for each of the three
                            cases.

                        
 

                        
1. Request processing by OCSP
                              servers

                        
 

                        
   The
                              behavior of an OCSP server will be
                              different whether the OCSP 

                        
   server
                              is a CA acting as an OCSP responder, is an
                              OCSP Responder 

                        
   which

                              received a delegation from one or more
                              CAs, or is a locally 

                        
   trusted

                              Responder.

                        
 

                        
1.1. Processing by a CA
                              acting as an OCSP responder

                        
 

                        
   The
                              OCSP responder SHALL maintain a list of
                              entries. Each entry 

                        
   SHALL

                              contain:

                        
 

                        
     -
                              the URI associated to the OCSP responder,
                              from which the OCSP 

                        
       requests

                              are received, 

                        
 

                        
     -
                              the DN from a CA,

                        
 

                        
     -
                              an issuing public key from a CA,

                        
 

                        
     -
                              the method(s) used to know for which
                              subset of certificates 

                        
       issued

                              by the CA it is responsible for, 

                        
 

                        
     -
                              the method(s) used to obtain the
                              revocation status of that 

                        
       subset

                              of certificates issued under that CA
                              issuing public key, 

                        
       and

                        
 

                        
     -
                              the method used to gain access and sign
                              with the private key 

                        
       corresponding

                              to the issuing public key.

                        
 

                        
   For
                              a given URI value, the OCSP responder
                              SHALL only use one CA 

                        
   key
                              pair value. 

                        
 

                        
   When
                              it receives an OCSP request on that URI,
                              the OCSP responder 

                        
   SHALL
                              handle exceptions according to section
                              2.3. 

                        
 

                        
   If
                              the OCSP request contains the name of a
                              requestor, the OCSP 

                        
   responder

                              SHALL verify whether there exists a
                              locally defined rule 

                        
   which

                              regulates access control.  If
                              this rule exists, it SHALL be 

                        
   followed.

                        
 

                        
   Then,
                              for each target certificate, the OCSP
                              responder SHALL verify 

                        
   whether
                              both the hash of the issuer's DN and the
                              hash of the issuer 

                        
   public
                              key which are present in the request are
                              eligible to a 

                        
   locally

                              defined rule which indicates that the OCSP
                              responder is 

                        
   responsible

                              to provide the revocation status of that
                              target 

                        
   certificate.  If
                              this rule exists, it SHALL be followed.

                        
 

                        
   Otherwise,

                              the OCSP responder SHALL determine whether
                              it is 

                        
   responsible

                              to provide the revocation status of that
                              target 

                        
   certificate

                              according to the following rule.

                        
 

                        
   For
                              each target certificate, the OCSP
                              responder SHALL verify whether 

                        
   both
                              the hash of the issuer's DN and the hash
                              of the issuer public 

                        
   key
                              which are present in the request match
                              respectively with the DN 

                        
   and
                              the hash of the public key of contained in
                              an entry from the 

                        
   list
                              of entries maintained by this OCSP
                              responder. 

                        
 

                        
   When
                              there is no match, then the OCSP responder
                              SHALL indicate the 

                        
   "unknown"

                              status and proceed with the next target
                              certificate from 

                        
   the
                              OCSP request.

                        
 

                        
   When
                              there is a match, then the OCSP responder
                              SHALL use the serial 

                        
   number
                              of the target certificate that is present
                              in the request and 

                        
   determine

                              the revocation status of that certificate
                              according to 

                        
   the
                              method(s) defined in the entry. 

                        
 

                        
   When
                              the revocation status is provided by the
                              server using a real 

                        
   time
                              access to a database of revocation
                              statuses of issued 

                        
   certificates,

                              then the thisUpdate field SHALL be present
                              in the

                        
   SingleResponse


                              response whereas the nextUpdate field
                              SHALL be 

                        
   missing.
                              

                        
 

                        
   Otherwise,

                              both the thisUpdate and the nextUpdate
                              fields SHALL be 

                        
   present
                              in the SingleResponse. 

                        
 

                        
   The
                              time at which this response will be signed
                              MUST be indicated in 

                        
   the
                              producedAt field from the SingleResponse.

                        
 

                        
   If a
                              singleRequestExtensions is present in the
                              request it MUST be 

                        
   processed.

                        
 

                        
   If
                              there is another target certificate
                              present in the request, it 

                        
   SHALL
                              be processed in the same way.

                        
 

                        
   If a
                              requestExtensions is present in the
                              request it MUST be 

                        
   processed.

                        
 

                        
   The
                              OCSP response MUST be signed using the CA
                              issuing private key.

                        
 

                        
 

                        
1.2. Processing by an OCSP
                              Responder

                        
 

                        
   For
                              each CA from which the OCSP Responder has
                              received a delegation, 

                        
   the
                              OCSP Responder SHALL maintain a list of
                              entries. 

                        
 

                        
   Each
                              entry SHALL contain:

                        
 

                        
     -
                              the URI associated to this OCSP Responder,
                              from which the OCSP 

                        
       requests

                              are received, 

                        
 

                        
     -
                              the DN from a CA,

                        
 

                        
     -
                              an issuing public key from a CA,

                        
 

                        
     -
                              the method(s) used to know for which
                              subset of certificates 

                        
       issued

                              by the CA it is responsible for, 

                        
 

                        
     -
                              the method(s) used to obtain the
                              revocation status of that 

                        
       subset

                              of certificates issued under that CA
                              issuing public key,

                        
 

                        
     -
                              an OCSP certificate, 

                        
 

                        
     -
                              the OCSP public key contained in that OCSP
                              certificate, and

                        
 

                        
     -
                              the method used to gain access and sign
                              with the OCSP private 

                        
       key

                              corresponding to that OCSP certificate.

                        
 

                        
   For
                              a given URI value, the OCSP Responder
                              SHALL only use one OCSP 

                        
   key
                              pair value. 
                              Therefore there cannot be two
                              entries with the 

                        
   same
                              URI value and a different OCSP public key
                              value.

                        
 

                        
   NOTE:
                              a BasicOCSPResponse can only be signed
                              using a single private 

                        
         key.
                              

                        
 

                        
   The
                              OCSP certificate SHALL be signed by the CA
                              issuing private key 

                        
   which

                              corresponds to the issuing CA public key
                              that is in this 

                        
   entry.

                        
 

                        
   When
                              it receives an OCSP request, the OCSP
                              responder SHALL handle 

                        
   exceptions

                              according to section 2.3. 

                        
 

                        
   If
                              the OCSP request contains the name of a
                              requestor, the OCSP 

                        
   responder

                              SHALL verify whether there exists a
                              locally defined rule 

                        
   which

                              regulates access control.  If
                              this rule exists, it SHALL be 

                        
   followed.

                        
 

                        
   For
                              each target certificate, the OCSP
                              Responder SHALL verify 

                        
   whether
                              both the hash of the issuer's DN and the
                              hash of the issuer 

                        
   public
                              key which are present in the OCSP request
                              match with those 

                        
   from
                              an entry.

                        
 

                        
   When
                              there is no match, then the OCSP Responder
                              SHALL indicate the 

                        
   "unknown"

                              status and proceed with the next target
                              certificate from 

                        
   the
                              OCSP request.

                        
 

                        
   When
                              there is a match, the OCSP Responder SHALL
                              use the serial 

                        
   number
                              of the target certificate this is present
                              in the OCSP 

                        
   request
                              to determine the revocation status of that
                              certificate 

                        
   according
                              to the method(s) indicated in the entry. 

                        
 

                        
   When
                              the revocation status is provided by the
                              server using a real 

                        
   time
                              access to a database of revocation
                              statuses of issued 

                        
   certificates,

                              then the thisUpdate field SHALL be present
                              in the

                        
   SingleResponse


                              response whereas the nextUpdate field
                              SHALL be 

                        
   missing.
                              

                        
 

                        
   Otherwise,

                              both the thisUpdate and the nextUpdate
                              fields SHALL be 

                        
   present
                              in the SingleResponse. 

                        
 

                        
   The
                              time at which this response will be signed
                              MUST be indicated in 

                        
   the
                              producedAt field from the SingleResponse.

                        
 

                        
   If a
                              singleRequestExtensions is present in the
                              request it MUST be 

                        
   processed.

                        
 

                        
   If
                              there is another target certificate
                              present in the request, it 

                        
   SHALL
                              be processed in the same way.

                        
 

                        
   If a
                              requestExtensions is present in the
                              request it SHALL be 

                        
   processed.

                        
 

                        
   The
                              OCSP response MUST be signed using the
                              OCSP private key.

                        
 

                        
   Unless
                              there is a local rule which states
                              differently, for every 

                        
   target

                              certificate which matches both with the
                              hash of a CA DN and an 

                        
   issuing

                              public key from an entry, the OCSP
                              certificate of that entry 

                        
   SHALL
                              be placed in the certs field.

                        
 

                        
   It
                              may happen, that none of the target
                              certificates from the OCSP

                        
   request

                              matches both with the hash of a CA DN and
                              an issuing public 

                        
   key
                              from an entry.  In
                              that case and unless a local rule states 

                        
   differently,

                              the certs field from the BasicOCSPResponse
                              SHOULD be 

                        
   kept
                              empty (to limit the disclose of the names
                              of the CAs from which 

                        
   the
                              OCSP Responder received a delegation
                              from).

                        
 

                        
1.3. Processing by a locally
                              trusted Responder

                        
 

                        
   For
                              each CA for which the locally trusted
                              Responder is 

                        
   authoritative,

                              the OCSP Responder SHALL maintain a list
                              of entries. 

                        
 

                        
   Each
                              entry SHALL contain:

                        
 

                        
     -
                              the URI associated to this OCSP Responder,
                              from which the OCSP 

                        
       requests

                              are received, 

                        
 

                        
     -
                              the DN from a CA,

                        
 

                        
     -
                              an issuing public key from a CA,

                        
 

                        
     -
                              the method(s) used to know for which
                              subset of certificates 

                        
       issued

                              by the CA it is responsible for, 

                        
 

                        
     -
                              the method(s) used to obtain the
                              revocation status of that 

                        
       subset

                              of certificates issued under that CA
                              issuing public key,

                        
 

                        
     -
                              the method used to gain access to the
                              private key in order to 

                        
       sign
                              the OCSP response. 

                        
 

                        
   For
                              a given URI value, the OCSP Responder
                              SHALL only use one private 

                        
   key.  Therefore

                              there cannot be two entries with the same
                              URI value 

                        
   and
                              a different method to gain access to the
                              appropriate private key.

                        
 

                        
   NOTE:
                              a BasicOCSPResponse can only be signed
                              using a single private 

                        
         key.
                              

                        
 

                        
   When
                              it receives an OCSP request, the OCSP
                              responder SHALL handle 

                        
   exceptions

                              according to section 2.3. 

                        
 

                        
   If
                              the OCSP request contains the name of a
                              requestor, the OCSP 

                        
   responder

                              SHALL verify whether there exists a
                              locally defined rule 

                        
   which

                              regulates access control.  If
                              this rule exists, it SHALL be 

                        
   followed.

                        
 

                        
   For
                              each target certificate, the OCSP
                              Responder SHALL verify 

                        
   whether
                              both the hash of the issuer's DN and the
                              hash of the issuer 

                        
   public
                              key which are present in the OCSP request
                              match with those 

                        
   from
                              an entry.

                        
 

                        
   When
                              there is no match, then the OCSP Responder
                              SHALL indicate the 

                        
   "unknown"

                              status and proceed with the next target
                              certificate from 

                        
   the
                              OCSP request.

                        
 

                        
   When
                              there is a match, the OCSP Responder SHALL
                              use the serial 

                        
   number
                              of the target certificate this is present
                              in the OCSP 

                        
   request
                              to determine the revocation status of that
                              certificate 

                        
   according
                              to the method(s) indicated in the entry. 

                        
 

                        
   When
                              the revocation status is provided by the
                              server using a real 

                        
   time
                              access to a database of revocation
                              statuses of issued 

                        
   certificates,

                              then the thisUpdate field SHALL be present
                              in the

                        
   SingleResponse


                              response whereas the nextUpdate field
                              SHALL be 

                        
   missing.
                              

                        
 

                        
   Otherwise,

                              both the thisUpdate and the nextUpdate
                              fields SHALL be 

                        
   present
                              in the SingleResponse. 

                        
 

                        
   The
                              time at which this response will be signed
                              MUST be indicated in 

                        
   the
                              producedAt field from the SingleResponse.

                        
 

                        
   If a
                              singleRequestExtensions is present in the
                              request it MUST be 

                        
   processed.

                        
 

                        
   If
                              there is another target certificate
                              present in the request, it 

                        
   SHALL
                              be processed in the same way.

                        
 

                        
   If a
                              requestExtensions is present in the
                              request it SHALL be 

                        
   processed.

                        
 

                        
   The
                              OCSP response MUST be signed using the
                              OCSP private key.

                        
 

                        
   The
                              certs field may contain no, one or several
                              OCSP certificates 

                        
   according
                              to local rules followed by the locally
                              trusted Responder.

                      

                  

                

              
              


              

              
Not broken.

              


              

              
/Stefan

              


              

              
                

                  

                    

                        
 

                        
 

                        
End
                            of comments

                          

                        


                          Denis

                      

                  

                

              

          

        

      

    

    

  


--------------060906090008050000070509--


From stefan@aaa-sec.com  Wed Feb 27 07:05:23 2013
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 DDAC721F8726 for ; Wed, 27 Feb 2013 07:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
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 41rOqvZoGOsO for ; Wed, 27 Feb 2013 07:05:22 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7480521F8659 for ; Wed, 27 Feb 2013 07:05:18 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 9E1864B3EE5 for ; Wed, 27 Feb 2013 16:05:13 +0100 (CET)
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 EpkoPNs9q_7W for ; Wed, 27 Feb 2013 16:04:43 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0C2904A9075 for ; Wed, 27 Feb 2013 16:04:43 +0100 (CET)
Received: (qmail 61867 invoked from network); 27 Feb 2013 15:04:42 -0000
Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.213]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 27 Feb 2013 15:04:42 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Wed, 27 Feb 2013 16:04:38 +0100
From: Stefan Santesson 
To: Denis Pinkas , Sean Turner 
Message-ID: 
Thread-Topic: [pkix] AD review of draft-ietf-pkix-rfc2560bis
In-Reply-To: <512E1A5B.2040005@bull.net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3444825885_27912951"
Cc: pkix@ietf.org
Subject: Re: [pkix] AD review of draft-ietf-pkix-rfc2560bis
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, 27 Feb 2013 15:05:23 -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_3444825885_27912951
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Denis,

Your comments that ere given during the WGLC has been responded to.
I's just not to your satisfaction.

As yor followup questions took quite some time, I was not aware that you
were not happy with responses to your issues when we prepared the
publication request to the IESG.
I'm still struggling to get time to respond to your last mail. But it will
happen before the end of the week.

/Stefan

From:  Denis Pinkas 
Date:  Wednesday, February 27, 2013 3:38 M
To:  Sean Turner , Stefan Santesson 
Subject:  Re: [pkix] AD review of draft-ietf-pkix-rfc2560bis

>    =20
> =20
> Sean,
> =20
>  You said:
> =20
> =20
> =20
>> When we close on #1, I'll whack the LC button.
>> =20
>>  spt=20
> =20
>  May I  recall you that I addressed comments during the WGLC which have n=
ot
> been addressed=20
>  to my satisfaction and that Stefan sent me a private answer on February =
11,
> 2013 which iscopied below
> =20
>  At this time, Stefan has not yet send me a reply.
> =20
>  Deis
> =20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC
> =20
>  Denis,
> =20
>=20
> =20
> =20
> I will review your comments.
> =20
> Unfortunately I won't be able to do so this eek.
> =20
>=20
> =20
> =20
> This document has already been sent to the IESG with a reques for
> publication.
> =20
> I will check in what way the comments will be handled.
> =20
=20
> =20
> =20
> /Stefan
> =20
>=20
> =20
>  =20
> From:  Denis Pinkas 
  Date:  Monday, February 11, 2013 3:18 PM
>  To:  Stefan Santesson 
>  Cc:  pkix 
>  Subject:  Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC
> =20
> =20
>=20
> =20
> =20
>> =20
>> =20
>> =20
>> =20
>>=20
>> Stefan,
>> =20
>> =20
>> =20
>> I have finally reviewed your disposition of comments. I have used draft =
13.
>> =20
>> =20
>> =20
>> I will not address the comments in sequence, but I will consider four
>> categories:
>> =20
> =20
>> =20
>> Category 1) Some comments which seem to be solved. Yes indeed,they may b=
e a
>> few of them !
>> =20
>> =20
>> =20
>> Category 2) Some comments whih might possibly be solved at the WG level.
> =20
>> =20
>> =20
>> Category 3) Some comments that I will address at the IETF last call leve=
l,
>> rater than the WG last call level, since I disagree
>>  that it is =B3new ways to say thesame thing=B2 and it is likely to be a was=
te
>> of time for both of us to arge again at the WG level
>>  (these comments are commented as =B3not broken=B2).
>>=20
>> =20
>> =20
>> Category 4) Some typos and editorials found while reading draft 13.
>> =20
>>  >> =20
>> =20
>> =20
>> CATEGORY 1
>> =20
>> =20
>> =20
>> Comment 4 (was editorial).
>> =20
>> =20
> =20
>> Comment 5.
>> =20
>> =20
>> =20
>> Comment 6.=20
>> =20
>> =20
>> =20
>> Comment 19. Solve, since =B3unknown=B2 seems now to be also allowed for
>> non-issued certificates
>>  (even if the OCSP responder is using a direct access to the certificate
>> database). See comment 8.
>> =20
>> =20
>> =20
>> Comment 13: Acceptble, since the text uses =B3MAY=B2.
>> =20
>> =20
>> =20
>> Comment 18.=20
>> =20
>> =20
>>=20
>> Comment 22.
>> =20
>> =20
>> =20
>> Comment 23.
>> =20
>> =20
>> =20
>> Comment 28.
>> =20
>> =20
>> =20
>> CATEGORY 1
>> =20
>> =20
>> =20
>> Comment 8: You have changed the meaning of the revoked state in a way th=
at is
>> not what I requested.
>> =20
>> =20
>> =20
>> The original text was:
>> =20
>> =20
> =20
>>    The "revoked" state indicates that the certificate as been revoked
>> =20
>>    (either permanantly or temporarily (on hold)).
>> =20
>> =20
>> =20
>> The new ext is:
>> =20
>> =20
>> =20
>>   The "revoked" state indicates that the certificate has been revoked
>> =20
>>    eithe permanently or temporarily on hold (i.e. the revocation reason
>> =20
>>    is certificateHold).
>> =20
>> =20
>> =20
>> By doing this, you do not allow any other case in the future to have a
>> temporary revocation: =B3temporarily on  hold=B2
>>  is not the same as =B3temporarily  revoked=B2.
>> =20
>> =20
>> =20
>> I propose the following rewording
>> =20
>> =20
>> =20
>>    The "revoked" state indicates that the certificate has been revoked
>> =20
>>   either permanently or temporarily (e.g. placed on hold).
>> =20
>> =20
>> =20
>> The way the text from draft 13 is now written seems to allow using eithe=
r
>> =B3unknown=B2 or =B3revoked=B2 for non-issued certificates.
>>  If this is the intent, then the good news is that this does not come an=
ymore
>> into conflict with the French rules which apply for
>>  the Administration since OCSP responders from CAs used by the French
>> Minitries having a direct access to the database
>>  of issued certificates will be able to use =B3unknown=B2, rather than =B3revo=
ked=B2
>> and the reason code =B3onhold=B2.
>> =20
>> =20
>> =20
>> However,  the current text is still mandating the use of Extended Revoke
>> Definition, but the rational for its need it is very poor.
>>  As I have said on the PKIX list, the fact that the revcation date is
>> January 1rst, 1970 is fully sufficient to know that we are in tha
>>  very special case, and you have not provided a rational to say the cont=
rary.
>> =20
>> =20
>> =20
>> So we could get rid of it, =8A but the text from section 4.4.8 states:
> =20
>> =20
>> =20
>>    This extension MAY be present in other responses to signal thatthe
>> =20
>>    responder implements the extended revoked definition in section 2.2.
> =20
>> =20
>> =20
>> I have difficulties to understand what is really meant there (=B3other
>> responses=B2 ?), since the text states:
>> =20
>> =20
>> =20
>>    This extension idicates that the responder supports the extended
>> =20
>>    definition of the "revked" status to also include non-issued
>> =20
>>    certificates according to section 2.2.
>> =20
>>=20
>> =20
>> Since both =B3unknown=B2 and revokd=B2 can be used, it would be desirable to b=
e
>> able to include the same extension in both cases,
>  but in that case that extension should be renamed.
>> =20
>> =20
>> =20
>> I would propose to rename it: "non-issued certificate=B2 which means that =
the
>> associated CA has no rcord of ever having issued
>>  a certificate with the certificate serial number in the request (I stil=
l
>> consider it as unnecessary in the case of =B3revoked=B2, but it would be
>>  very useful in the case of =B3uknown=B2). Of course, the text from section
>> 4.4.8 would need to be revised.
>>  >> =20
>> =20
>> I propose the following:
>> =20
>> =20
>> =20
>> 4.4.8  Non-issued certificate extension
>> =20
>> =20
>> =20
>>    This extensionMUST be included in the OCSP response when the OCSP
>> =20
>>    responder knows hat the CA identified in the request has no record
>> =20
>>    of ever having issued acertificate with the certificate serial
>> =20
>>    number indicated in the request.
>> =20
>> =20
>> =20
>>    Clients do not have to pase this extension in order to determine
>> =20
>>    the status of certificates in resonses.
>> =20
>> =20
>> =20
>>    This extension is identified by the object identifer id-pkix-ocsp-
>> =20
>>    non-issued-cert.
>> =20
>> =20
>> =20
>>      id-pkix-ocsp-non-issued-cert OBJECT IDENTIFIER ::=3D {id-pkix-ocsp 9}
>> =20
>> =20
>> =20
>>    The alue of the extension SHALL be NULL. This extension MUST NOT be
>> =20
>>    marked crtical.
>> =20
>> =20
>> =20
>> Then the text on page 8 would need to be rearraned.
>> =20
>> =20
>> =20
>> The current text is:
>> =20
>> =20
>> =20
>>    This state MAY also be returned if the
>> =20
>>    associated CA has no record of ever having issued a certificate with
>> =20
>>    the ertificate serial number in the request, using any current or
>> =20
>>    prevous issuing key (referred to as a "non-issued" certificate in
>> =20
>>    this documet).
>> =20
>> =20
>> =20
>>    The "unknown" state indicates that the responder doesn' know about
>> =20
>>    the certificate being requested.
>> =20
>> =20
>> =20
>>    NOTE: The "revoked" tate for known non-issued certificate serial
>> =20
>>          numbers is allowed in oder to reduce the risk of relying
>> =20
>>          parties using CRLs as a fall back mechanism, which would be
>> =20
>>          considerably higher if an "uknown" response was returned.
>> =20
>> =20
>> =20
>>    When a responder responds revked to a status request for a non-
>> =20
>>    issued certificate, the responder UST include the extended revoked
>> =20
>>    definition response extension (sectin 4.4.8) in the response,
>> =20
>>    indicating that the OCSP responder support the extended definition
>> =20
>>    of revoked state to also cover non-issuedcertificates. In addition,
>> =20
>>    the SingleResponse related to this non-issud certificate;
>> =20
>> =20
>> =20
>>     - MUST provide the revocation reason certificateHold (6),
>> =20
>> =20
>>=20
>>     - MUST specify the revocationTime January 1, 1970, and
>> =20
>> =20
>> =20
>>     - MUST NOT include a CRL References extension (section 4.4.2) or any
>> =20
>>       CRL Entry Extensions (section 4.4.5).
>> =20
>> =20
>> =20
>> Proposed  text for a replacement:
>> =20
>> =20
>> =20
>>    The "unknown" state indicaes that the responder doesn't know about
>> =20
>>    the certificate being requested
>> =20
>> =20
>> =20
>>    If the OCSP responder knows that CA identified in the requst has
>> =20
>>    no record of ever having issued a certificate with the certificate
>> =20
>>    serial number in the requet, using any current or previous issuing
>> =20
>>    key (referred to as a "non-isued" certificate in this document),
>> =20
>>    the OCSP responder SHALL respond either =B3revoked =B3 or =B3unknown=B2.
>> =20
>>=20
>> =20
>>    Note: The "revoked" state for known non-issued certificate serial
>> =20
>>   numbers is allowed in order to reduce the risk of relying parties
>> =20
>>    sing CRLs as a fall back mechanism, which would be possible when
>> =20
>>    the unknown" response is returned.
>> =20
>> =20
>> =20
>>    When a responder responds revoked or unknown to a status request
>>=20
>>    for a non-issued certificate, the responder MUST include the
>> =20
>>    non-ssued certificate extension (see section 4.4.8) in the
>> =20
>>    response.=20
>>=20
>> =20
>> =20
>>    When a responder responds revoked to a status request for a non
>> =20
>>    issued certificate, in addition, the responder:
>> =20
>> =20
>> =20
>>     - MUST provide the revocation reason certificateHold (6),>> =20
>> =20
>> =20
>>     - MUST specify the revocationTime January 1, 1970, and;
>> =20
>> =20
>> =20
>>     - MUST NOT include a CRL References extension section 4.4.2) or any
>> =20
>>       CRL Entry Extensions (section 4.4.5).
>> =20
>> =20
> =20
>> Finally,  the last bullet on page 4 should be reworded:
>> =20
>> =20
>> =20
>> Current text:
>> =20
>> =20
>> =20
>>       o Secion 4.4.8 specifies a new extension that indicates that the
>> =20
>>          reponder supports the extended use of the "revoked" response
>> =20
>>          for non-issued certificates defined in section 2.2.
>> =20
>> =20
>> =20
>>Proposed  replacement text:
>> =20
>> =20
>> =20
>>       o  Section 4.4.8 specifies a nw extension that indicates that
>> =20
>>          the OCSP responder knows that CA dentified in the request
>> =20
>>          has no record of ever having issued a cetificate with the
>> =20
>>          certificate serial number present in the request, as defined
>> =20
>>          in section 2.2.
>> =20
>> =20
>> =20
>> Comment 9: Solve, if the comment above may be solved.
>> =20
>> =20
>> =20
>> Comment 20:  This  comment is preliminary classified by you as =B3not brok=
en=B2.
>> However, since you aked: =B3If you don=B9t replace 4.2.2.3,
>>  then what really are you missing ?=B2, I will provide you with an answer.
>> =20
>> =20
>> =20
>> This is the wrong way to state th question. Providing an ASN.1 syntax as=
 in
>> 4.2.1 is not enough: the use of every parameter
>>  MUST be explained usin English words. So if you explain the use of ever=
y
>> parameter after the desciption of the ASN.1 syntax
>>  in section 4.2.1. then section 4.2.2.3 is no more neded and thus can be
>> deleted.
>> =20
>> =20
>> =20
>> The answer to your question =B3what is really missing=B2 is a description of=
 the
>> use of every parameter listed in he ASN.1 in section 4.2.1
>> =20
>> =20
>> =20
>> Comment 21.
>> =20
>> =20
>> =20
>> While  can agree in general with the intent of the text, I do not unders=
tand
>> the first sentence of the Note which speaks of =B3CA key rollover=B2
>>  and is copied below:
>> =20
>> =20
> =20
>>    Note: CA key rollover is not prohibited when issuing a certificate
>> =20
>>         for an authorized responder for backwards compatibility with
>> =20
>>          RFC 2560 [RFC2560]. That is, it is not prohibited to issue a
>> =20
>>         certificate for an authorized responder using a differet
>> =20
>>          issuing key than the key used to issued the certificate being
>> =20
>>         checked for revocation. However, such practice is strongly
>> =20
>>          discouraed since clients are not required to recognize a
>> =20
>          responder with such certificate as an authorized responder.
>> =20
>> =20
>> =20
>>  would propose to delete it, since it does not add anything and thus to
>> have:
>>=20
>> =20
>> =20
>>    Note: For backwards compatibility with RFC 2560 [RFC2560], it is
>> =20
>>          not prohibited to issue a certificate for an authorized>> =20
>>          responder using a different issuing key than the key used to
>>=20
>>          issued the certificate being checked for revocation.
>> =20
>>         However, such practice is strongly discouraged since clients
>> =20
>>         are not required to recognize a responder with such
>> =20
>>          certificateas an authorized responder.
>> =20
>> =20
>> =20
>> Comment 24: The ASN.1 module in annex B.1 is still wrong, since it does =
not
> define NoCheck.=20
>> =20
>> =20
>> =20
>> Comment 26: You asked for explanations. Let me prvide you with an exampl=
e
>> when CRLs re being used by the OCSP responder
>>  in the background. The OCSP responder needs to make sure hat the CRL it
>> uses is valid. If it is simply using published CRLs
>>  (i.e. no trusted link with the CA), it needs to make sure that the CA w=
hich>> has issued the CRL has no been revoked.
>> =20
>> =20
>> =20
>> In France, there is aroot CA for the Administration. However, the use of
>> that root CA is optional. hus a Ministry may have its own root,
>>  but may also have its key certified by the root CA of the Administratio=
n.
>> The OCSP respondermay use the root CA of the Ministry,
>>  while a relying party may use the roo CA of the Administration (or the
>> reverse) to validate the CRL for the target certificate.
>>  Thus the revocation status will be different if the certifcate of the C=
A of
>> the Ministry is revoked by the root CA of the Administration.
>> =20
>> =20
>> =20
>> CATEGORY 3
>> =20
>> =20
>> =20
>> Comments 2, 3, 7, 10, 12, 14, 15, 16, 17 25 and 27.
>> =20
>> =20
>> =20
>> =20
>> =20
>> CATEGORY 4
>> =20
>> =20
>> =20
>> Page 4. The indntation of the bullets in section 1 is not uniform.
>>  Bullets 1, 4, 5 and 9 have roblems.
>> =20
>> =20
>> =20
>> Page 4. The fact that there is now an Annex B.2 dealingwith the 2008 ASN=
.1
>> syntax is missing. This should be added.
>> =20
>> =20
>> =20
>> Pge 10. Change =B3Se further section 4.2.2.2=B2 into =B3See  further section
>> 4.2.2.2=B2
>>=20
>> =20
>>=20
>>  Denis
>> =20
>> =20
>> =20
>> =20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>> =3D=3D=3D=3D=3D=3D=3D=3D =20
>> =20
>> =20
>> =20
>> =20
>>> =20
>>> Denis,
>>> =20
>>> >>> =20
>>> =20
>>> Responding to your comments below.
>>> =20
>>>=20
>>> =20
>>> =20
>>> Howeer, one general remark to make recurring comments easier to underst=
and.
>>> =20
>>=20
>>> =20
>>> =20
>>> The WG decided to adopt a minimalistic approach to updating RF 2560. Th=
at
>>> means that=20
>>> =20
>>>. We don't change anything from RFC 2560 unless it is broken, or the
>>> industry clearly needclarifications in order to avoid interoperability
>>> issues.=20
>>> 2. We retai the document structure of RFC 2560 as much as possible to a=
llow
>>> easy comparison of what the changes are in comparison with RFC 250.
>>> =20
>>>=20
>>> =20
>>> =20
>>> One can always think up more clever ways to write thins out in words. B=
ut
>>> that also comes with a risk.
>>> =20
>>> The current words ha been around for a long time and we know from
>>> experience which words workedto produce working implementations, and wh=
ich
>>> did not.
>>> =20
>>> Introducing new ways to say te same thing may introduce new problems an=
d
>>> people might disagree on what the new perfect wording should be. And th=
is
>>> could go on forever.
>>> =20
>>>=20
>>> =20
>>> =20
>> So when my reply is "Not broken", then that is because the current wordi=
ng
>>> does not have such problems that is merits a change.
>>> =20
>>>=20
>>> =20
>>> =20
>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>>  =20
>>> From:  Denis Pinkas >>>  Date:  Sunday, January =
20, 2013 5:12 PM
>>>  To:  Stefan Santesson ,  Stephen Kent 
>>>  Cc:  pkix 
>>>  Subject:  Re: [pkix] Review of 260-bis draft 8. Answer to WGLC
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> Please find 32 comments on draft-ietf-pkix-rfc2560bis
>>>> =20
>>>> =20
>>>> =20
>>>> 1. The document states:
>>>> =20
>>>>  >>> separately>
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>=20
>>> =20
>>> =20
>>> Responded to separately.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> 2. The current text from section 2 states:
>>>> =20
>>>> =20
>>>> =20
>>>> 2.  Protocol Overview
>>>> =20
>>>> =20
>>>> =20
>>>>    In lieu of or as a supplement to checking against a peridic CRL, it
>>>> =20
>>>>    may be necessary to obtain timely information regardig the
>>>> =20
>>>>    revocation status of a certificate (cf. RFC5280], Section 3.3.
>>>> =20
>>>>    Examples include high-value funds transfer or large stock trades.
>>>> =20
>>>> =20
>>>> =20
>>>>    The Online Certificate Status Protocol (OCSP) enables applications =
to
>>>> =20
>>>>    determinethe (revocation) state of an identified certificate. OCSP
>>>> =20
>>>>    may be used to satisfy some of the operational requirments of
>>>> =20
>>>>    providing more timey revocation information than is possible with
>>>> =20
>>>>    CRLs and may also be used to obtain additional status information.
>>>> =20
>>>> =20
>>>> =20
>>>> This text is misleading because readers may think that CPS necessarily
>>>> provides =B3timely information=B2.
>>>> =20
>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> "may" does not mean "necessarily".
>>>=20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>> Proposed text replacement:
>>>> =20
>>>>=20
>>>> =20
>>>>=20
>>>>    The Online Certificate Status Protocol (OCSP) is a client-server
>>>> =20
>>>>    protocol  whic enables applications to obtain the revocation status
>>>> =20
>>>>    of one or more certificates either "good", "revoked", or "unknown".
>>>> =20
>>>> =20
>>> =20
>>>>    The revocation statu may be provided by the server either using a
>>>> =20
>>>>    real time access to a database ofissued certificates, or using a
>>>> =20
>>>>    batch access to a atabase of issued certificates, or using a
>>>> =20
>>>>    real time access to a database of evocation statuses of issued
>>>> =20
>>>>    certificates,  or using a batch access o a database of revocation
>>>> =20
>>>>    statuses of issued certificates, or usin CRLs, or using a
>>>> =20
>>>>    combination  of base CRLs and delta CRLs.
>>>> =20
>>>> =20
>>>> =20
>>>>    In the first case it is possible to obtain timely revocation status
>>>> =20
>>>>    information,  wheeas in the other cases, the freshness of the
>>>> =20
>>>>    revocation  statu is not better than the mechanisms it is based on.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken
>>> =20
>>>=20
>>> =20
>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> 3. The current text from section 2 states:
>>>> =20
>>>> =20
>>>> =20
>>>>    An OCSP client issues a status request to an OCSP resonder and
>>>> =20
>>>>    Suspends acceptance of the certificate in question ntil the
>>>> =20
>>>>    responder provides a response.
>>>> =20
>>>> =20
>>>> =20
>>>>    This protocol specifies the data that needs to be exchanged between
>>>> =20
>>>    an application checking the status of a certificate and the server
>>>> =20
>>>    providing that status.
>>>> =20
>>>> =20
>>>> =20
>>>> Thus is insufficient for an verview. More details are needed to know w=
hat
>>>> the document provides,
>>>> i particular that the request may contain several requests for seveal
>>>> certificates issued by different CAs.
>>>> The possibility of using extensions should alo be advertised.
>>>> =20
>>>> =20
>>>> =20
>>>> Proposed text replacement:
>>>> =20
>>>>  >>>> =20
>>>>    When using OCSP, an OCSP client issues a certificate revocation
>>>> =20
>>>>    status request to an OCSP responder or one or more certificates
>>>> =20
>>>>    issued by the same CA or for one or morecertificates issued by
>>>> =20
>>>>    different  CAs and then suspends acceptanceof the certificate(s)
>>>> =20
>>>>    in question unil the responder provides a response.
>>>> =20
>>>> =20
>>>> =20
>>>>    This document specifies the ata that needs to be exchanged between
>>>> =20
>>>>    an application checkng the status of a certificate and the server
>>>> =20
>>>>    providing that status.
>>>> =20
>>>> =20
>>>> =20
>>>>    OCSP may also provide additional status inforation using
>>>> =20
>>>>    extensions.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not boken
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>> =20
>>>>=20
>>>> 4. Page 6. Editorial. Punctuation and a CR/LF are missing.
>>>> =20
>>>> =20
>>>> =20
>>> The  text states:
>>>> =20
>>>> =20
>>>> =20
>>>>    3. the request contains the information needed by the responder If
>>>> =20
>>>>       any one of the prior coditions are not met, the OCSP responder
>>>> =20
>>>>       produces an error message; otherwise, it returns a definitive
>>> =20
>>>>       response.
>>>> =20
>>>> =20
>>>> =20
>>>> It  should state:
>>>> =20
>>>> =20
>>>> =20
>>>>    4. the request contains the information neded by the responder.
>>>> =20
>>>> =20
>>>> =20
>>>>       If any one of the prior conditions are not met, the OCSP respond=
er
>>>> =20
>>>>       produces an error message; otherwise, it returns a definitive
>>>> =20
>>>>       response.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>> =20
>>> Fixed in draft 10.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>> =20
>>>>=20
>>>> 5. On page 7, the text states:
>>>> =20
>>>> =20
>>>> =20
>>>>    All definitive response messages SHALL be digitally signed. The key
>>>> =20
>>>    used to sign the response MUST belongto one of the following:
>>>> =20
>>>> =20
>>>> =20
>>>>    -  the CA who issued the certificate in question
>>>> =20
>>>>    -  a Trusted Responder whose public key is trusted by the requester
>>>> =20
>>>>    -  a CA Dsignated Responder (Authorized Responder) who holds a
>>>>  >>>>       specially marked certificate issued directly by the CA, in=
dicating
>>>> =20
>>>>      that the responder may issue OCSP responses for that CA.
>>>> =20
>>>> =20
>>>> =20
>>>> The  paragraph is ambiguous on several aspects.
>>>>=20
>>>> =20
>>>> =20
>>>> Delegation  is addressed in at least three different places, but with
>>>> different terms and conditions.
>>>>  If some one picks a sentence in one paragraph rather tan another, it =
will
>>>> lead to a different conclusion.
>>>>  RFCs are supposed to be clear.
>>>> =20
>>>> =20
>>>> =20
>>>> On page 10, the current text states in ection 2.6 OCSP Signature Autho=
rity
>>>> Delegation states:
>>>> =20
>>>> =20
>>>>=20
>>>>    The key that signs a certificate's status information need not be t=
he
>>>> =20
>>>>    same key that signed the certificate. A certificate's issuer
>>>> =20
>>>>   explicitly  delegates OCSP signing authority by issuing a certificat=
e
>>>> =20
>>>>    containing a unique value for extenedKeyUsage in the OCSP signer's
>>>> =20
>>>>    certificate.  This certificate MST be issued directly to the
>>>> =20
>>>>    responder by the cognizant CA.
>>>> =20
>>>> =20
>>>> =20
>>>> On page 16, ther is a section 4.2.2.2 called =B3Authorized Responders=B2
>>> dealing with the same topic.
>>>> =20
>>>> =20
>>>> =20
>>>> Section  4.2.2.2 states:
>>>> =20
>>> =20
>>>> =20
>>>>    The key that signs a certificate's status information need not e th=
e
>>>> =20
>>>>    same key that signed the certificate. It is necessary howeverto
>>>> =20
>>>>    ensure that the entity signing this information is authorized to do
>>>> =20
>>>>    so.  Therefore a certificate's issuer MAY either sign the OCSP
>>>> =20
>>>>    responses  itself o it MAY explicitly designate this authority to
>>>> =20
>>>>    another  entity.  OSP  signing delegation SHALL be designated by th=
e
>>>> =20
>>>>    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certifiate
>>>> =20
>>>>    extension  included in the OCSP response signer's certificate.  his
>>>> =20
>>>>    certificate  MUST be issued directly by the CA that issued the
>>>> =20
>>>>    certificate  in question.
>>> =20
>>>> =20
>>>> =20
>>>>    The CA SHOULD use the same issuing key to issue a elegation
>>>> =20
>>>>    certificate  as was used to sign the certificate bein checked for
>>>> =20
>>>>    revocation.  Systems  relying on OCSP esponses MUST recognize a
>>>> =20
>>>>    delegation  certificate as being issued by the CA thatissued the
>>>> =20
>>>>    certificate  in question only if the delegation ertificate and the
>>>> =20
>>>>    certificate  being checked for revocation was signed by the same ke=
y.
>>>> =20
>>>> =20
>>>> =20
>>>> The  last sentence above in ellow is the key sentence that is missing =
in
>>>> the two other sections.
>>>> =20
>>>> =20
>>>> =20
>>>> Most implementations nly support the case where the OCSP Responder
>>> receives an OCSP certificate that is signed by the same key
>>>> that was used to sign the taget certificate. They do not support the c=
ase
>>>> where the OCSP Responder receives an OCSP certificate
>>>> that is signed by a key that is different fromthe one that was used to
>>>> sign the target certificate.
>>>> =20
>>>> =20
>>>> =20
>>>> It is inappropriate to have three setions dealing with the same topic =
with
>>>> a slightly different meaning.
>>>> =20
>>>> =20
>>>> =20
>>>> It is proposed the following.
>>>> =20
>>>>=20
>>>> =20
>>>> On page 7, after:
>>>> =20
>>>> =20
>>>> =20
>>>>    -  a CA Designated Responder (Authorized Responder) who holds a
>>>> =20
>>>>       specially marked certificate issued directly by the CA, indicati=
ng
>>> =20
>>>>       that the responder may issue OCSP responses for that CA.
>>>> =20
>>>>=20
>>>> =20
>>>> it is proposed to add =B3(see section 4.2.2.2 for further details)=B2, so =
tht
>>>> the reader knows that more details are provided later on.
>>>> =20
>>>> =20
>>>> =20
>>>> Then we do not need two sections to address delegation which start wit=
h the
>>>> same sentence:
>>>> =20
>>>> =20
>>>>=20
>>>>  =B3The key that sigs a certificate's status information need not be the
>>>> same key that signed he certificate=B2.
>>>> =20
>>>> =20
>>>> =20
>>>> It is thus proposed to delete section 26.
>>>> =20
>>>> =20
>>>> =20
>>>> Section  4.2.2.2 will thus remain the single section prviding full
>>>> details.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> I have added references to section 4.2.2.2 in the quoted sections in 2.=
2 and
>>> 2.6.
>>> =20
>>> (will be included in raft 11)
>>> =20
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>> 6. Page , the text states:
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>>    A definitive response message is composed of:
>>>> =20
>>>> =20
>>>> =20
>>>>    -  version of the respnse syntax
>>>> =20
>>>>    -  name of the reponder
>>>> =20
>>>>    -  responses for each of the certificates in a request
>>>> =20
>>>>    -  optional extensions
>>>> =20
>>>>    -  signature algorithm OID
>>>> =20
>>>>    -  signature computed across hash of te response
>>>> =20
>>>> =20
>>>> =20
>>>> This  description does ot fit with the ASN.1 syntax which is detailed
>>>> later on, and in particular:
>>>> =20
>>>>=20
>>>> =20
>>>>    ResponseData ::=3D SEQUENCE {
>>>> =20
>>>>       version              [0] EXPLICIT Version DEFAULT v1,
>>>> =20
>>>>       responderID              ResponderID,
>>>>  >>>>       producedAt               GeneralzedTime,
>>>> =20
>>>>       responses                SEQUENCE OF SingleResponse,
>>>> =20
>>>>       esponseExtensions   [1] EXPLICIT Extensions OPTIONAL }
>>>> =20
>>>> =20
>>>> =20
>>>> Proosed text replacement:
>>>> =20
>>>> =20
>>>> =20
>>>>    A definitive response message is composed of:
>>>> =20
>>>> =20
>>>> =20
>>>>    - a response status and if there is no error, the folloing:
>>>> =20
>>>>    - the version of the response syntax,
>>>> =20
>>>>    - an identifier of the OCSP server,
>>>> =20
>>>>   - the time at which the response was produced,
>>>>=20
>>>>    - single responses for each of the target certificates,
>>>> =20
>>>>    - optional etensions,
>>>> =20
>>>>    - the signature algorithm OID,
>>>> =20
>>>>    - the signatre computed across hash of the response, and
>>>> =20
>>>>    - optional certificate.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> This is an overview section. We ough not try to duplicate the level of
>>> detail provided in the detailed protocol secion.
>>> =20
>>> A "definitive response" according to tho 2.1 is a response to an eror-f=
ree
>>> request, so your first remark is redundant.
>>> =20
>>>=20
>>> =20
>>> =20
>>> I have added a note about time to the currnt list, and changed "name" t=
o
>>> identifier in bullet 2.
>>> =20
>>> (will be inclued in draft 11)
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> 7. The text states on page 7:
>>>> =20
>>>> =20
>>>> =20
>>>    The response for each of the certificates in a request consists of
>>>>=20
>>>> =20
>>>> =20
>>>>    -  target  certificate identifier
>>>> =20
>>>>    -  cetificate  status value
>>>> =20
>>>>    -  response  validity intervl
>>>> =20
>>>>    -  optional  extensions
>>>> =20
>>>> =20
>>>> =20
>>>> However,  there are no explaations for the purpose of these parameters=
 and
>>>> how they should be proessed.
>>>> =20
>>>> There  are also no explanations on how to process a single response an=
d how
>>>> to verify that it is its presence within the signed structre
>>>>  is valid or not valid. This is a major deficiency of the current
>>>> description of RC 2560 where there is no eplanation on how to validate
>>>>  a single reponse.
>>>> =20
>>>> =20
>>>> =20
>>>> Text  proposal to be added after:
>>>> =20
>>>> =20
>>>> =20
>>>>    Te purpose of the identifier of the OCSP server is to allow OCSP
>>>> =20
>>>>    clients to find whether the definitive response was signed by a CA
>>>> =20
>>>    or by an OCSP Responder.
>>>> =20
>>>> =20
>>>> =20
>>>>    The identifier of the OCSP server SHOULD either be the name or he
>>>> =20
>>>>    key from a CA, or the name or the key from a OCSP Responder.
>>>> =20
>>>> =20
>>>> =20
>>>>    Unless there exist local rules (wich are outside the scope of this
>>>> =20
>>>>    document)  for verifying that a single response is correctly signed=
,
>>>> =20
>>>>    the following applies:
>>>> =20
>>>> =20
>>>> =20
>>>>    When the identifier matchs with the name of the CA which has issued
>>>> =20
>>>>    the target certificate or corresponds to the key used to issue the
>>>> =20
>>>>    target  certificate, then a single response is correctly signed
>>>> =20
>>>>    only if the digital signature of the OCSP response is valid using t=
he
>>>> =20
>>>>    key used to sign the target certificate.
>>>> =20
>>>> =20
>>>> =20
>>>>    When the identifier does not match with the name of the CA hich has
>>>> =20
>>>>    issued the target certificate or dos not correspond to the key used
>>>> =20
>>>>    to issue the target certificate, then an single response is correct=
ly
>>>> =20
>>>>    signed only if :
>>>> =20
>>>> =20
>>>> =20
>>>>          (a)  there exists in the response an OCSP certificate issued =
by
>>>> =20
>>>>              the  CA which has issued the target certificate which is
>>>> =20
>>>>              signed  by the same key as the one used to issue the
>>>> =20
>>>>              target  certificate, and
>>>> =20
>>>> =20
>>>> =20
>>>>          (b)  the digital signature of the OCSP response is valid usin=
g
>>>> =20
>>>>              the  subjectPublicKey contained in this OCSP certificate.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>> All of this is already covered by the document.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> 8. The text states on page 7:
>>>> =20
>>>> =20
>>>> =20
>>>>    The "revoked" state indicates that the certificate has been revoked
>>>> =20
>>>>    (either  permanently or temporarily (on hold)). This  state MAY als=
o be
>>>> =20
>>>>    returned if the responder knows that the requested certificate has
>>>> =20
>>>>    never been issued during the history of the associated CA using any
>>>> =20
>>>>    current or previous issuing key.
>>>> =20
>>>> =20
>>>> =20
>>>> The  text is ambiguous because there are two embedded parenthesis and =
it is
>>>> unclear whether the inner parenthesis means =B3i.e=B2 or =B3e.g=B2.
>>>>  This single sentence may let think that on hold is the single case fo=
r
>>>> temporarily revocation. Since neither X.509 nor RFC 5280 address=20
>>>>  the case of a temporary revocation in the context of an OCSP response=
 (but=20
>>>> only in the context of CRLs), we are able to add another case=20
>>>>  of temporary revocation which will only apply in the context of OCSP.
>>>> =20
>>>> =20
>>>> =20
>>>> The  above sentence using the terms =B3never been issued during the hist=
ory=20
>>>> of the associated CA =B3does  not capture the fact=20
>>>>  that it could be issued in the future, hence why using =B3not yet been =
used=B2=20
>>>> would  be more appropriate.
>>>> =20
>>>> =20
>>>> =20
>>>> Finally,  it would have been more logical to use =B3unknown=B2. So it is=20
>>>> important to add a note to explain why we have chosen that case for =B3l=
egacy=20
>>>> clients=B2,=20
>>>>  otherwise the people who have not participate to the exchanges will n=
ot=20
>>>> understand.
>>>> =20
>>>> =20
>>>> =20
>>>> Proposed text replacement:
>>>> =20
>>>> =20
>>>> =20
>>>>    The "revoked" state indicates that the certificate has been revoked=
,
>>>> =20
>>>>    either permanently or temporarily.
>>>> =20
>>>> =20
>>>> =20
>>>>    A certificate may be temporarily revoked either because it is=20
>>>> =20
>>>>    placed on hold (i.e. the revocation reason is certificateHold) or=20
>>>> =20
>>>>    because the responder is able to know, using a positive list of=20
>>>> =20
>>>>    issued certificates, that the serial number from the requested=20
>>>> =20
>>>>    certificate has not yet been used by the CA to issue a certificate=20
>>>> =20
>>>>    (i.e. the revocation reason is notIssuedOrIrregularlyIssued).
>>>> =20
>>>> =20
>>>> =20
>>>> NOTE: The "revoked" state is used rather than the =B3unknown=B2 state, to
>>>> =20
>>>>       make sure that relying parties that were conformant to RFC 2560
>>>> =20
>>>>       will not use CRLs as a fall back mechanism.=20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> I removed the double parenthesis and adopted your clarification with re=
gard=20
>>> to "on hold".=20
>>> =20
>>>=20
>>> =20
>>> =20
>>> The text in draft 10 has changed from what you have commented on. I bel=
ieve=20
>>> that text is better.
>>> =20
>>>=20
>>> =20
>>> =20
>>> You "Note" has problems.
>>> =20
>>> 1. We do not prevent responders to respond "unknown" if their assessmen=
t is=20
>>> that this is an appropriate response, considering what they know about =
the=20
>>> requested serial number. Thus the term "is used" is misleading.=20
>>> 2. This mechanisms does not "make sure" that the clients do anything. I=
t's=20
>>> up to the discretion of the relying party to decide what source of=20
>>> revocation checking they rely on. This does however reduce the risk of=20
>>> clients falling back to CRL:s=20
>>> 3. This mechanism is not just relevant to old clients, but also to new =
one=20
>>> for the same reason.=20
>>> =20
>>>=20
>>> =20
>>> =20
>>> I have adopted a modified version of your Note:
>>> =20
>>>=20
>>> =20
>>> =20
>>> =20
>>>    NOTE: The "revoked" state for known non-issued certificate serial
>>> =20
>>>          numbers is allowed in order to reduce the risk of relying
>>> =20
>>>          parties using CRLs as a fall back mechanism, which would be
>>> =20
>>>          considerably higher if an "unknown" response was returned.
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 9. The text states on page 8:
>>>> =20
>>>> =20
>>>> =20
>>>>    When a responder responds revoked to a status request for a non-
>>>> =20
>>>>    issued  certificate, the responder MUST also;
>>>> =20
>>>> =20
>>>> =20
>>>>     - include the extended revoked definition response extension
>>>> =20
>>>>       (section  4.8), indicating that the OCSP responder supports the
>>>> =20
>>>>       extended  definition of revoked state to also cover non-issued
>>>> =20
>>>>       certificates,
>>>> =20
>>>> =20
>>>> =20
>>>>     - provide the revocation reason certificateHold (6), and;
>>>> =20
>>>> =20
>>>> =20
>>>>     - specify the revocation date January 1, 1970.=20
>>>> =20
>>>> =20
>>>> =20
>>>> As  already explained on the PKIX list, using the revocation reason=20
>>>> certificateHold is not appropriate=20
>>>>  because it changes the meaning of certificateHold.=20
>>>> =20
>>>> =20
>>>> =20
>>>> The  extended revoked definition response extension is a means to sign=
al=20
>>>> that it not a true certificate hold but a =B3not issued certificate=B2.=20
>>>>  Legacy applications cannot take advantage of it.=20
>>>> =20
>>>> =20
>>>> =20
>>>> Some  applications which handle non repudiation enter a waiting state =
when=20
>>>> the revocation reason certificateHold is used thus=20
>>>>  it is not appropriate to overload the meaning.
>>>> =20
>>>> =20
>>>> =20
>>>> It is possible to use another enumeration for signalling that specific=
=20
>>>> case:
>>>> =20
>>>> notIssuedOrIrregularlyIssued  (7).
>>>> =20
>>>> =20
>>>> =20
>>>> Thus  for new applications it would be much better to use=20
>>>> notIssuedOrIrregularlyIssued (7) as already proposed on the PKIX list.
>>>> =20
>>>> =20
>>>> =20
>>>> The above sentence uses the text:=20
>>>> =20
>>>> =20
>>>> =20
>>>> =B3a status request for a non-issued certificate=B2=20
>>>> =20
>>>> =20
>>>> =20
>>>> whereas it would be more appropriate to state:=20
>>>> =20
>>>> =20
>>>> =20
>>>> =B3a status request for a serial number which has not been used by the C=
A or=20
>>>> used irregularly to issue a certificate=B2.
>>>> =20
>>>> =20
>>>> =20
>>>> Placing the ASN.1 description at such a place in the document is=20
>>>> inappropriate since the ASN.1 structures have not yet been described.=20
>>>> Thus only the functional aspects should be mentioned, but not the ASN.=
1=20
>>>> implications.
>>>> =20
>>>> =20
>>>> =20
>>>> BTW, the description should follow the same order as the ASN.1. This i=
s not=20
>>>> the case.=20
>>>> =20
>>>> =20
>>>> =20
>>>> This text should be deleted from this section and the appropriate text=
=20
>>>> should be added when the parameters of the response are described.=20
>>>> =20
>>>> =20
>>>> =20
>>>> The text proposed in the previous comment should be sufficient at this=
 time=20
>>>> of reading.
>>>> =20
>>>> =20
>>>> =20
>>>> In addition, section 4.4.8  Extended  Revoked Definition should be del=
eted.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> The referred text has been updates in draft 09.
>>> =20
>>>=20
>>> =20
>>> =20
>>> This has been discussed on the list and you have yet to convince the li=
st of=20
>>> your new reason code.
>>> =20
>>> I disagree as the risk of running into problems with the deployed base =
of=20
>>> application is hugely larger with introduction of a new reason code, ra=
ther=20
>>> than using certificateHold.
>>> =20
>>> No application should be broken, since no application have business ask=
ing=20
>>> for non-issued cert serial numbers in the first place. Secondly, no=20
>>> application can assume that a certificateHold reason will be cleared an=
y=20
>>> time soon.
>>> =20
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> 10. The text states on page 8:
>>>> =20
>>>> =20
>>>> =20
>>>> 2.4  Semantics of thisUpdate, nextUpdate and producedAt
>>>> =20
>>>> =20
>>>> =20
>>>> This  section is misplaced. At this time of reading, the reader does n=
ot=20
>>>> know that thisUpdate, nextUpdate and producedAt are values=20
>>>>  used by the ASN.1 structures. It is appropriate to describe what thes=
es=20
>>>> parameters mean when the ASN.1 syntax is described.=20
>>>>  The current ASN.1 syntax is very badly described. One would expect th=
at=20
>>>> after every ASN.1 structure description every parameter is described.=20
>>>>  Unfortunately this is not the case.=20
>>>> =20
>>>> =20
>>>> The  text from this section is not aligned with the text that is prese=
nt in=20
>>>> section 4.2.2.1.=20
>>>> =20
>>>> =20
>>>> =20
>>>> In  particular, in section 2.4:
>>>> =20
>>>> =20
>>>> =20
>>>>    If nextUpdate is not set, the responder is indicating that newer
>>>> =20
>>>>    revocation  information is available all the time.
>>>> =20
>>>> =20
>>>> =20
>>>> While  in section 4.2.2.1:
>>>> =20
>>>> =20
>>>> =20
>>>>    Responses  where the nextUpdate value is not set are equivalent=20
>>>> =20
>>>>    to a CRL with no time for nextUpdate (see Section 2.4).
>>>> =20
>>>> =20
>>>> =20
>>>> It is not appropriate to have two different descriptions in two differ=
ent=20
>>>> places.
>>>> =20
>>>> =20
>>>> =20
>>>> Delete  section 2.4. See comment number 19 for the description of thes=
e=20
>>>> parameters.
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>> The current text segments fits well into a protocol overview section.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> 11. Section 2.5 is also misplaced. They use values from the ASN.1 synt=
ax=20
>>>> which has not yet been described.=20
>>>>  They should be moved or incorporated in the document once the ASN.1=20
>>>> description has been done.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 12. Remainder: Section 2.6 should be deleted (see comment number 5).
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 13. Section 2.7 states:
>>>> =20
>>>> =20
>>>> =20
>>>> 2.7  CA Key Compromise
>>>> =20
>>>> =20
>>>> =20
>>>>    If an OCSP responder knows that a particular CA's private key has
>>>> =20
>>>>    been compromised, it MAY return the revoked state for all
>>>> =20
>>>>    certificates  issued by that CA.
>>>> =20
>>>> =20
>>>> =20
>>>> This  section is misleading and should be removed. The reason is the=20
>>>> following:
>>>> =20
>>>> =20
>>>> =20
>>>> The  relying party must verify that the singleResponse is signed by a=20
>>>> responder which is entitled to do so.
>>>> =20
>>>> =20
>>>> =20
>>>> a) If the CA key has been compromised and if the response is signed by=
 that=20
>>>> CA key then the singleResponse will be discarded=20
>>>>  when performing the certification path validation whatever the conten=
t of=20
>>>> the response may be.
>>>> =20
>>>> =20
>>>> =20
>>>> b) If the CA key which has issued the OCSP certificate has been compro=
mised=20
>>>> and if the response is signed by the key present=20
>>>>  in the OCSP certificate then the singleResponse will be discarded whe=
n=20
>>>> performing the certification path validation
>>>>  whatever the content of the response may be.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> Security  must be provided using the validation of the certification p=
ath.=20
>>>> Thus it does not matter what the OCSP responder states.
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>> An OCSP responder does not have to be chained to the broken CA. The rel=
ying=20
>>> party may have other trust configuration at choice.
>>> =20
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>>=20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> 14. The text states on page 11:
>>>> =20
>>>> =20
>>>> =20
>>>> 3.2  Signed  Response Acceptance Requirements
>>>> =20
>>>> =20
>>>> =20
>>>>    Prior to accepting a signed response as valid, OCSP clients SHALL
>>>> =20
>>>>    confirm  that:
>>>> =20
>>>> =20
>>>> =20
>>>>    1. The certificate identified in a received response corresponds to
>>>> =20
>>>>       that  which was identified in the corresponding request;
>>>> =20
>>>> =20
>>>> =20
>>>>    2. The signature on the response is valid;
>>>> =20
>>>> =20
>>>> =20
>>>>    3. The identity of the signer matches the intended recipient of the
>>>> =20
>>>>       request.
>>>> =20
>>>> =20
>>>> =20
>>>>    4. The signer is currently authorized to sign the response.
>>>> =20
>>>> =20
>>>> =20
>>>>    5. The time at which the status being indicated is known to be
>>>> =20
>>>>       correct  (thisUpdate) is sufficiently recent.
>>>> =20
>>>> =20
>>>> =20
>>>>    6. When available, the time at or before which newer information wi=
ll
>>>> =20
>>>>       be  available about the status of the certificate (nextUpdate) i=
s
>>>> =20
>>>>       greater  than the current time.
>>>> =20
>>>> =20
>>>> =20
>>>> This  section is misplaced since it uses terms from the ASN.1 syntax a=
nd=20
>>>> the protocol description has not yet been made,=20
>>>>  since it is the next section 4. Its text is not correct either.=20
>>>> =20
>>>> =20
>>>> =20
>>>> This  description does not take into account the fact that a=20
>>>> BasicOCSPResponse may  contain one or several SingleResponses.=20
>>>>  In particular, the sentence =B3The signer is currently authorized to si=
gn=20
>>>> the response=B2 is misleading because a signer=20
>>>>  may be authorized to include some SingleResponses but not necessarily=
 all=20
>>>> of them.=20
>>>> =20
>>>> =20
>>>> =20
>>>> The  appropriate explanations should be done after the description of =
the=20
>>>> response, when describing the processing of the response.
>>>> =20
>>>> =20
>>>> =20
>>>> Delete  that section.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 15. On page 12, after the ASN.1 description, the only parameters which=
 are=20
>>>> described are:=20
>>>> =20
>>>> hashAlgorithm, issuerNameHash,  issuerKeyHash and serialNumber.
>>>> =20
>>>> =20
>>>> =20
>>>> This is insufficient.  In order to cover the full list of parameters, =
the=20
>>>> following text is proposed:
>>>> =20
>>>> =20
>>>> =20
>>>>    requestorName  is optional and MAY be used by the server for access=
=20
>>>> =20
>>>>    control and audit purposes.
>>>> =20
>>>> =20
>>>> =20
>>>>    requestList  contains one or more single requests.
>>>> =20
>>>> =20
>>>> =20
>>>>    requestExtensions  is OPTIONAL.  Any specific extension is OPTIONAL=
.
>>>> =20
>>>>    The critical flag SHOULD NOT be set for any of them. Section 4.4=20
>>>> =20
>>>>    suggests  several useful extensions.  Additional  extensions MAY be=
=20
>>>> =20
>>>>    defined in additional RFCs.
>>>> =20
>>>> =20
>>>> =20
>>>>    reqCert  contains the identifier of a target certificate.
>>>> =20
>>>> =20
>>>> =20
>>>>    issuerNameHash  is the hash of the Issuer's distinguished name.  Th=
e=20
>>>> =20
>>>>    hash shall be calculated over the DER encoding of the issuer's name=
=20
>>>> =20
>>>>    field in the certificate being checked.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    issuerKeyHash  is the hash of the Issuer's public key.  The hash=20
>>>> =20
>>>>    shall be calculated over the value (excluding tag and length) of th=
e=20
>>>> =20
>>>>    subject  public key field in the issuer's certificate.  The hash=20
>>>> =20
>>>>    algorithm  used for both these hashes, is identified in=20
>>>> =20
>>>>    hashAlgorithm. =20
>>>> =20
>>>> =20
>>>> =20
>>>>       The primary reason to use the hash of the CA's public key in=20
>>>> =20
>>>>       addition  to the hash of the CA's name, to identify the issuer,=20
>>>> =20
>>>>       is that it is possible that two CAs may choose to use the same=20
>>>> =20
>>>>       name  (uniqueness in the Name is a recommendation that cannot be=
=20
>>>> =20
>>>>       enforced).  Two CAs will never, however, have the same public ke=
y=20
>>>> =20
>>>>       unless  the CAs either explicitly decided to share their private=
=20
>>>> =20
>>>>       key, or the key of one of the CAs was compromised.
>>>> =20
>>>> =20
>>>> =20
>>>>    serialNumber  is the serial number of the certificate for which=20
>>>> =20
>>>>    status is being requested.
>>>> =20
>>>> =20
>>>> =20
>>>>    singleRequestExtensions  is OPTIONAL.  Any specific extension is=20
>>>> =20
>>>>    OPTIONAL.  The critical flag SHOULD NOT be set for any of them.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    The requestor MAY choose to sign the OCSP request.  In that case, t=
he
>>>> =20
>>>>    signature is computed over the tbsRequest structure.  If the reques=
t
>>>> =20
>>>>    is signed, the requestor SHALL specify its name in the requestorNam=
e
>>>> =20
>>>>    field.  Also, for signed requests, the requestor MAY include
>>>> =20
>>>>    certificates  that help the OCSP responder verify the requestor's
>>>> =20
>>>>    signature in the certs field of Signature.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>> The current text is short, but it is actually sufficient from the conte=
xt of=20
>>> the ASN.1 definitions of the section. This is a detailed protocol secti=
on=20
>>> and the reader need to understand ASN.1 in any case to understand and=20
>>> implement the section.
>>> =20
>>> The information about criticality is already covered in the extension=20
>>> section.
>>> =20
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 16. Section 4.1.2 is called: =B3Notes on the Request Syntax=B2
>>>> =20
>>>> =20
>>>> =20
>>>> The  first paragraph has been moved after the description of issuerKey=
Hash=20
>>>> and  thus is no more needed.
>>>> =20
>>>> =20
>>>> =20
>>>> The  second paragraph has been moved after the description of=20
>>>> requestExtensions.=20
>>>>  However, the sentence=20
>>>>  =B3 Unrecognized extensions MUST be ignored (unless they have the criti=
cal=20
>>>> flag set and are not understood)=B2=20
>>>>  has been deleted since it applies to the OCSP responder and not to th=
e=20
>>>> OCSP client. Thus it is no more needed.
>>>> =20
>>>> =20
>>>> =20
>>>> The  third paragraph applies to signed requests. However, it should be=
long=20
>>>> to a section dedicated on how clients should build OCPS requests,=20
>>>>  which is currently missing. See the next comment.
>>>> =20
>>>> =20
>>>> =20
>>>> This  section should be deleted.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 17. There should be a new section called: =B3Requirements for OCSP clien=
ts=B2.=20
>>>> =20
>>>> =20
>>>> =20
>>>> It is important first to re-advertise that the request may be about se=
veral=20
>>>> certificates.=20
>>>>  Thus it is important to describe the process for building a request, =
which=20
>>>> is currently missing.
>>>> =20
>>>> =20
>>>> =20
>>>>    An OCSP request allows getting in the same response the revocation=20
>>>> =20
>>>>    status of one or more certificates.  In order to request the=20
>>>> =20
>>>>    status of one or more certificates in a single request, OCSP=20
>>>> =20
>>>>    clients  SHALL follow the following rules :
>>>> =20
>>>> =20
>>>> =20
>>>>    For each candidate certificate, OCSP clients SHALL verify=20
>>>> =20
>>>>    whether  there exists a locally defined rule for the certificate in=
=20
>>>> =20
>>>>    question  which indicates the URI where the OCSP responder is=20
>>>> =20
>>>>    located.  If this rule exists, it SHALL be followed.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    Otherwise,  OCSP clients SHALL determine whether the candidate=20
>>>> =20
>>>>    certificate  contains an AIA extension with an accessMethod which=20
>>>> =20
>>>>    contains the id-ad-ocsp OID.  If it is the case, the accessLocation=
=20
>>>> =20
>>>>    contains a uniformResourceIdentifier (URI) which indicates the=20
>>>> =20
>>>>    location of the OCSP server for that certificate.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    Certificates  that contain the same URI MAY be grouped in a single=20
>>>> =20
>>>>    request.
>>>> =20
>>>> =20
>>>> =20
>>>> Note:  For each candidate certificate, when performing the path=20
>>>> =20
>>>>        validation  algorithm, the OCSP client SHOULD verify that the=20
>>>> =20
>>>>        current  time is within the validity period of the target=20
>>>> =20
>>>>        certificate.  Certificates  which are outside their validity=20
>>>> =20
>>>>        period  SHOULD NOT be included in the request.
>>>> =20
>>>> =20
>>>> =20
>>>>    The requestor MAY choose to sign the OCSP request. In that case, th=
e
>>>> =20
>>>>    signature is computed over the tbsRequest structure. If the request
>>>> =20
>>>>    is signed, the requestor SHALL specify its name in the requestorNam=
e
>>>> =20
>>>>    field. Also, for signed requests, the requestor MAY include
>>>> =20
>>>>    certificates  that help the OCSP responder verify the requestor's
>>>> =20
>>>>    signature in the certs field of Signature.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>>=20
>>> =20
>>> =20
>>> Your text may provide guidance that could be useful to some implementer=
s,=20
>>> but is completely beyond this document and further, not generally appli=
cable=20
>>> or true.
>>> =20
>>> As an example, an organisation may setup an in house locally configured=
 OCSP=20
>>> responder that responds to all certificates "out there" that is relevan=
t to=20
>>> that organisation.
>>> =20
>>> Such clients would just blindly send OCSP requests to their local respo=
nder,=20
>>> disregarding any information in the cert.
>>> =20
>>> It's totally beyond this spec to have an opinion about this.
>>> =20
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 18. The text states on page 14:
>>>> =20
>>>> =20
>>>> =20
>>>>    The responder MAY include certificates in the
>>>> =20
>>>>    certs field of BasicOCSPResponse that help the OCSP client verify t=
he
>>>> =20
>>>>    responder's  signature. If no certificates are included then certs
>>>> =20
>>>>    SHOULD be absent.
>>>> =20
>>>> =20
>>>> =20
>>>> While  this sentence is true, it is not sufficient. In order to allow=20
>>>> verifying every SingleResponse,=20
>>>>  it is important to include the relevant certificates which are pertin=
ent=20
>>>> to every SingleResponse.
>>>> =20
>>>> =20
>>>> =20
>>>> Proposed  full text replacement:
>>>> =20
>>>> =20
>>>> =20
>>>>    The responder MAY include certificates in the certs field of=20
>>>> =20
>>>>    BasicOCSPResponse  that help the OCSP client verify the responder's=
=20
>>>> =20
>>>>    signature.
>>>> =20
>>>> =20
>>>> =20
>>>>    For every SingleResponse where the responder is not a CA, the=20
>>>> =20
>>>>    responder  SHALL include the relevant OCSP certificate in the certs=
=20
>>>> =20
>>>>    field of BasicOCSPResponse in order to allow the OCSP client=20
>>>> =20
>>>>    verifying  the responder was entitled to include that SingleRespons=
e=20
>>>> =20
>>>>    in the signed BasicOCSPResponse.
>>>> =20
>>>> =20
>>>> =20
>>>>    If no certificates are included then certs SHOULD be absent.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>>=20
>>> =20
>>> =20
>>> This requirement would break backwards compatibility with RFC 2560.
>>> =20
>>> Further this would not be needed for a locally configured responder.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 19. Page 15. The ASN.1 syntax should be changed in order to be able to=
 use=20
>>>> the enumeration case 7 that is not used for CRLs.=20
>>>>  This leads to the following change:
>>>> =20
>>>> =20
>>>> =20
>>>> Current  text:
>>>> =20
>>>> =20
>>>> =20
>>>>        revocationReason    [0]     EXPLICIT  CRLReason OPTIONAL }
>>>> =20
>>>> =20
>>>> =20
>>>> Proposed  text change:
>>>> =20
>>>> =20
>>>> =20
>>>> Current  text:
>>>> =20
>>>> =20
>>>> =20
>>>>        revocationReason     [0]     EXPLICIT  RevocationReason OPTIONA=
L }
>>>> =20
>>>> =20
>>>> =20
>>>> RevocationReason ::=3D ENUMERATED {
>>>> =20
>>>>         unspecified                    (0),
>>>> =20
>>>>         keyCompromise                  (1),
>>>> =20
>>>>         cACompromise                   (2),
>>>> =20
>>>>         affiliationChanged             (3),
>>>> =20
>>>>         superseded                     (4),
>>>> =20
>>>>         cessationOfOperation           (5),
>>>> =20
>>>>         certificateHold                (6),
>>>> =20
>>>>         notIssuedOrIrregularlyIssued    (7),
>>>> =20
>>>>         removeFromCRL                  (8),
>>>> =20
>>>>         privilegeWithdrawn             (9),
>>>> =20
>>>>         aACompromise                  (10) }
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>>=20
>>> =20
>>> =20
>>> You have to convince the list about your new reason code.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 20. Page 15. After the ASN.1 syntax, there is no description of every=20
>>>> parameter, neither on its use=20
>>>>  (except a few words in section 4.2.2.1 Time about thisUpdate,  nextUp=
date=20
>>>> and producedAt).
>>>> =20
>>>> =20
>>>> =20
>>>> Every parameter needs to be described and explained.
>>>> =20
>>>> =20
>>>> =20
>>>>    responderID  indicates either the name or the key from a CA, or the=
=20
>>>> =20
>>>>    name or the key from a OCSP Responder.
>>>> =20
>>>> =20
>>>> =20
>>>>    producedAt  indicates the time at which this response was signed.
>>>> =20
>>>> =20
>>>> =20
>>>>    responses  contains one or more single responses.
>>>> =20
>>>> =20
>>>> =20
>>>>    responseExtensions  is OPTIONAL.  Any specific extension is OPTIONA=
L.
>>>> =20
>>>>    The critical flag may or may not be set.
>>>> =20
>>>> =20
>>>> =20
>>>>    certID is usually a copy of the same field which was placed in the=20
>>>> =20
>>>>    request, but for OCSP responders which pre-produce signed responses=
=20
>>>> =20
>>>>    certID may be the identifier of a target certificate that was not=20
>>>> =20
>>>>    present in the request (see the end of section 4.2).
>>>> =20
>>>> =20
>>>> =20
>>>>    certStatus  indicates the status of the certificate: either good,=20
>>>> =20
>>>>    revoked or unknown.
>>>> =20
>>>> =20
>>>> =20
>>>>    thisUpdate  indicates the time at which the status being indicated=20
>>>> =20
>>>>    is known to be correct.
>>>> =20
>>>> =20
>>>> =20
>>>>    nextUpdate  indicates the time at or before which newer information=
=20
>>>> =20
>>>>    will be available about the status of the certificate.  If=20
>>>> =20
>>>>    nextUpdate  is not set, the server is indicating that newer=20
>>>> =20
>>>>    revocation  information is available all the time.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    If nextUpdate is set, it often corresponds to the {thisUpdate,=20
>>>> =20
>>>>    nextUpdate}  interval in CRLs.  Responses whose nextUpdate value is=
=20
>>>> =20
>>>>    earlier than the local UTC time value SHOULD be considered=20
>>>> =20
>>>>    unreliable.  Responses  whose thisUpdate time is later than the loc=
al=20
>>>> =20
>>>>    UTC time SHOULD be considered unreliable.
>>>> =20
>>>> =20
>>>> =20
>>>>    singleExtensions  is OPTIONAL.  Any specific extension is OPTIONAL.
>>>> =20
>>>>    The critical flag SHOULD NOT be set for any of them.
>>>> =20
>>>> =20
>>>> =20
>>>>    revocationTime  indicates the time at which the certificate was=20
>>>> =20
>>>>    revoked.
>>>> =20
>>>> =20
>>>> =20
>>>>    revocationReason  is OPTIONAL.  It includes all the cases that are=20
>>>> =20
>>>>    present in CRLReason used for CRLs and an additional case 7 which i=
s
>>>> =20
>>>>    not used for CRLs.  Case 7 is called notIssuedOrIrregularlyIssued.=20
>>>> =20
>>>> =20
>>>> =20
>>>>       - "notIssued" corresponds to the case where the certificate=20
>>>> =20
>>>>          serial  number that was sent was erroneous and has not yet=20
>>>> =20
>>>>          been  used by the CA at the time of the query,
>>>> =20
>>>> =20
>>>> =20
>>>>       - "irregularlyIssued" corresponds to the case where the=20
>>>> =20
>>>>          certificate  serial number that was sent really exists in a=20
>>>> =20
>>>>          certificate  that is correctly signed, but to its knowledge=20
>>>> =20
>>>>          the CA has not issued a certificate with such a serial=20
>>>> =20
>>>>          number.   As an example, it may have been issued by the CA=20
>>>> =20
>>>>          because  the RA was compromised.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    When a responder responds revoked to a status request for which it=20
>>>> =20
>>>>    knows that the serial number has not been used by the CA or has=20
>>>> =20
>>>>    been irregularly used irregularly to issue a certificate, then=20
>>>> =20
>>>>    in RevokedInfo the responder MUST:
>>>> =20
>>>> =20
>>>> =20
>>>>       - specify the revocationTime :  January 1, 1970,
>>>> =20
>>>>       - provide the revocationReason: notIssuedOrIrregularlyIssued (7)=
.
>>>> =20
>>>> =20
>>>> =20
>>>>    and in SingleResponse the responder MUST NOT include the nextUpdate=
.
>>>> =20
>>>> =20
>>>> =20
>>>>    The response MUST include a SingleResponse for each certificate in
>>>> =20
>>>>    the request and SHOULD NOT include any additional SingleResponse
>>>> =20
>>>>    elements.  However,  there is one exception:=20
>>>> =20
>>>> =20
>>>> =20
>>>>       OCSP  responders MAY pre-produce signed responses specifying the=
=20
>>>> =20
>>>>       status of certificates at a specified time.  The time at which=20
>>>> =20
>>>>       the  status was known to be correct SHALL be reflected in the=20
>>>> =20
>>>>       thisUpdate  field of the response.=20
>>>> =20
>>>> =20
>>>> =20
>>>>       OCSP  responders that pre-generate status responses MAY return=20
>>>> =20
>>>>       responses  that include additional SingleResponse elements if
>>>> =20
>>>>       necessary  to improve response pre-generation performance or cac=
he
>>>> =20
>>>>       efficiency  (as permitted in [RFC5019]).
>>>> =20
>>>> =20
>>>> =20
>>>> Since the text above provides all the explanations at the level of the=
=20
>>>> ASN.1 parameters, the general text=20
>>>>  from section 4.2.2.3 Basic Response is no more need and should be del=
eted.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Preliminary I would say "not broken".
>>> =20
>>> If you don't replace 4.2.2.3, then what really are you missing?
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 21. 0n page 16, there is a section 4.2.2.2 called =B3Authorized Responde=
rs=B2
>>>> =20
>>>> =20
>>>> =20
>>>> Section  4.2.2.2 states:
>>>> =20
>>>> =20
>>>> =20
>>>>    (=8A)
>>>> =20
>>>>    This certificate MUST be issued directly by the CA that issued the
>>>> =20
>>>>    certificate  in question.
>>>> =20
>>>> =20
>>>> =20
>>>>    The CA SHOULD use the same issuing key to issue a delegation
>>>> =20
>>>>    certificate  as was used to sign the certificate being checked for
>>>> =20
>>>>    revocation.  Systems relying on OCSP responses MUST recognize a
>>>> =20
>>>>    delegation  certificate as being issued by the CA that issued the
>>>> =20
>>>>    certificate  in question only if the delegation certificate and the
>>>> =20
>>>>    certificate  being checked for revocation was signed by the same ke=
y.
>>>> =20
>>>> =20
>>>> =20
>>>> This  section would need to reformatted to address CA requirements fir=
st=20
>>>> and then OCSP responder requirements:
>>>> =20
>>>> =20
>>>> =20
>>>>    (=8A)
>>>> =20
>>>>    This certificate MUST be issued directly by the CA that issued the
>>>> =20
>>>>    certificate  in question.  The CA SHOULD use the same issuing key t=
o=20
>>>> =20
>>>>    issue a delegation certificate as was used to sign the certificate=20
>>>> =20
>>>>    being  checked for revocation.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    Systems  relying on OCSP responses MUST be able to recognize a=20
>>>> =20
>>>>    delegation  certificate as being issued by the CA that issued the=20
>>>> =20
>>>>    certificate  in question if the delegation certificate and=20
>>>> =20
>>>>    the certificate being checked were signed by the same key.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> I disagree. The CA is actually free to do anything, but cannot expect t=
he=20
>>> client to recognise the responder as authorised unless the same private=
 key=20
>>> is used.
>>> =20
>>> The current text places the requirement where they belong.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 22. On page 17, the text states:
>>>> =20
>>>> =20
>>>> =20
>>>>    They MUST reject the
>>>> =20
>>>>    response if the certificate required to validate the signature on t=
he
>>>> =20
>>>>    response  fails to meet at least one of the following criteria:
>>>> =20
>>>> =20
>>>> =20
>>>> This is ambiguous. It is inappropriate to have a negative statement li=
ke=20
>>>> =B3They MUST reject=B2.=20
>>>>  The sentence should be turned in the positive form =B3They SHALL accept=
=B2=20
>>>> =20
>>>> =20
>>>> =20
>>>> Since  the ASN.1 syntax has now be described, it is possible to be mor=
e=20
>>>> specific.
>>>> =20
>>>> =20
>>>> =20
>>>> The  first occurrence of the word =B3response=B2 should be changed into=20
>>>> =B3singleResponse=B2, while the second occurrence=20
>>>>  of the word =B3response=B2 should be changed into =B3ResponseData=B2
>>>> =20
>>>> =20
>>>> =20
>>>> Proposed  text replacement:
>>>> =20
>>>> =20
>>>> =20
>>>>    They SHALL accept a singleResponse if the certificate required to=20
>>>> =20
>>>>    validate the signature placed on the ResponseData meets one of the=20
>>>> =20
>>>>    following  criteria:
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> No, this change is not backwards compatible.
>>> =20
>>> So state the requirements for rejection is not equivalent to stating=20
>>> requirements for acceptance.
>>> =20
>>> There may be other locally configured reasons to reject in addition to =
those=20
>>> listed in the standard.
>>> =20
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> 23. On page 17, the text states:
>>>> =20
>>>> =20
>>>> =20
>>>>    3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
>>>> =20
>>>>    extension  and is issued by the CA that issued the certificate in
>>>> =20
>>>>    question as stated above."
>>>> =20
>>>> =20
>>>> =20
>>>> In  order to be crystal clear, it is proposed to change the wording in=
 the=20
>>>> following way:
>>>> =20
>>>> =20
>>>> =20
>>>>    3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
>>>> =20
>>>>    extension  and was signed by the CA using the same key that used=20
>>>> =20
>>>>    to issue the certificate in question.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> No, issuing with another key is not prohibited, and may be accepted by =
some=20
>>> clients as an authorised responder.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 24. On page 17, the text states:
>>>> =20
>>>> =20
>>>> =20
>>>>    This SHOULD be a non-critical extension. The value of the extension=
=20
>>>> =20
>>>>    SHALL be NULL.
>>>> =20
>>>> =20
>>>> =20
>>>> The ASN.1 syntax is missing. Add:=20
>>>> =20
>>>> =20
>>>> =20
>>>>    NoCheck ::=3D NULL
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Moving this to a separate discussion.
>>> =20
>>> I'm not sure what the preferred way to describe this is.
>>> =20
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> 25. Remainder: On page 18, the general text from section 4.2.2.3 Basic=
=20
>>>> Response is no more needed and=20
>>>>  should be deleted. See comment 20.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> 26. On page 24, text should be added to the Security consideration sec=
tion:
>>>> =20
>>>> =20
>>>> =20
>>>> Different results when using OCSP and CRLs
>>>> =20
>>>> =20
>>>> =20
>>>>    OCSP clients or verifiers must build and verify a certification pat=
h=20
>>>> =20
>>>>    for each target certificate up to a trusted root.  When an OCSP=20
>>>> =20
>>>>    Responder is using published CRLs, it must also build and verify a=20
>>>> =20
>>>>    certification  path for the CRLs it uses up to a trusted root.
>>>> =20
>>>> =20
>>>> =20
>>>>    However, it should be realized that the root used by an OCSP=20
>>>> =20
>>>>    Responder to verified these CRLs is not necessarily the same as the=
=20
>>>> =20
>>>>    one that would be used by the OCSP client, if it were going to veri=
fy=20
>>>> =20
>>>>    the CRLs itself.  Hence the revocation status may not be identical=20
>>>> =20
>>>>    in both cases.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> I don't understand this one.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> 27. On page 24, text should be added to the Security consideration sec=
tion:
>>>> =20
>>>> =20
>>>> =20
>>>> Denial of service attack using a flood of queries
>>>> =20
>>>> =20
>>>> =20
>>>>    A denial of service vulnerability is evident with respect to a floo=
d=20
>>>> =20
>>>>    of queries.  The  production of a cryptographic signature=20
>>>> =20
>>>>    significantly  affects response generation cycle time, thereby=20
>>>> =20
>>>>    exacerbating  the situation.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    The flood of queries may either come from a flood attack or from th=
e=20
>>>> =20
>>>>    fact that there are too many certificates supported by the same OCS=
P=20
>>>> =20
>>>>    responder.  In the later case, the number of queries can be=20
>>>> =20
>>>>    reduced by using a technique similar to the splitting of CRLs:=20
>>>> =20
>>>> =20
>>>> =20
>>>>       When a block of certificates have been issued with the same=20
>>>> =20
>>>>       accessLocation  in the AIA extension field of these certificates=
,=20
>>>> =20
>>>>       then the accessLocation should be changed.  In this way, a given=
=20
>>>> =20
>>>>       OCSP  server will only be responsible for a block of certificate=
s.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> If the security considerations section is talking about splitting OCSP=20
>>> responders in this way, then the document itself need to introduce the=20
>>> subject.
>>> =20
>>> I would suggest that it is beyond this update to do so.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 28. On page 31, the text states.
>>>> =20
>>>> =20
>>>> =20
>>>>    An alternative to this module that conforms to the 2002 version of=20
>>>> =20
>>>>    ASN.1 may be found in Section 4 of [RFC5912].=20
>>>> =20
>>>> =20
>>>> =20
>>>> RFC  5912 omits to define the nocheck extension. Thus it is inappropri=
ate=20
>>>> to refer to RFC 5912.=20
>>>> =20
>>>> =20
>>>> =20
>>>> The  corrected module should be defined in this new draft.=20
>>>>  A corrected module is provided in draft-pinkas-rfc2560bis-03.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Will move this (as stated above) to a separate discussion.
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> 29. Different topics are not covered by the document. These topics are=
=20
>>>> important.=20
>>>>  The following comments propose text to be placed in annexes. Three an=
nexes=20
>>>> are being proposed.
>>>> =20
>>>> =20
>>>> =20
>>>> Note:  The texts are extracted from draft-pinkas-rfc2560bis-03.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>> Each such amendment need to be thoroughly reviewed and motivated.
>>> =20
>>>=20
>>> =20
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> 30. First annex being proposed. This annex is important, because key=20
>>>> rollover is not addressed in the draft.
>>>> =20
>>>> =20
>>>> =20
>>>> KEY ROLLOVER
>>>> =20
>>>> =20
>>>> =20
>>>> 1. CA that directly supports an OCSP service
>>>> =20
>>>> =20
>>>> =20
>>>>    When a CA that directly supports an OCSP service performs a key=20
>>>> =20
>>>>    rollover:
>>>> =20
>>>> =20
>>>> =20
>>>>    - for certificates issued under the old key, the CA SHALL continue=20
>>>> =20
>>>>      to sign the revocation status of OCSP responses with that old key=
=20
>>>> =20
>>>>      at least until all these certificates are expired, and
>>>> =20
>>>> =20
>>>> =20
>>>>    - for certificates issued under the new key, the CA SHALL change th=
e=20
>>>> =20
>>>>      accessLocation  in the AIA extension field of these certificates=20
>>>> =20
>>>>      and sign the revocation status of OCSP responses with that new ke=
y=20
>>>> =20
>>>>      at least until all these certificates are expired.
>>>> =20
>>>> =20
>>>> =20
>>>>    Note: The change in accessLocation is necessary when the CA rekeys=20
>>>> =20
>>>>          to  meet the following constraints imposed by this standard:=20
>>>> =20
>>>> =20
>>>> =20
>>>>             1)  a BasicOCSPResponse can only be signed using a single=20
>>>> =20
>>>>                private key;=20
>>>> =20
>>>> =20
>>>> =20
>>>>             2)  the response must be signed using the same CA key that=
=20
>>>> =20
>>>>                was used to sign the certificate in question; and
>>>> =20
>>>> =20
>>>> =20
>>>>             3)  the OCSP response needs to cover all the certificates=20
>>>> =20
>>>>                queried in the OCSP request.
>>>> =20
>>>> =20
>>>> =20
>>>> 2. CA that uses OCSP responders
>>>> =20
>>>> =20
>>>> =20
>>>>    When a CA that uses OCSP Responders performs a key rollover, then=20
>>>> =20
>>>>    it MUST either designate a new OCSP Responder or keep the current=20
>>>> =20
>>>>    OCSP Responder(s).
>>>> =20
>>>> =20
>>>> =20
>>>>    If the CA designates a new OCSP Responder, then it SHALL change the=
=20
>>>> =20
>>>>    accessLocation  in the AIA extension field for the newly issued=20
>>>> =20
>>>>    certificates  and issue an OCSP certificate to the new OCSP Respond=
er=20
>>>> =20
>>>>    using its new key.
>>>> =20
>>>> =20
>>>> =20
>>>>    If the CA keeps the same OCSP Responder(s), then it SHALL continue=20
>>>> =20
>>>>    to use the same accessLocation(s) in the AIA extension field for th=
e=20
>>>> =20
>>>>    newly issued certificates and issue an OCSP certificate to the=20
>>>> =20
>>>>    appropriate  OCSP Responder(s) using its new key.
>>>> =20
>>>> =20
>>>> =20
>>>>    Note: The CA may need to continue issuing certificates to the OCSP=20
>>>> =20
>>>>    Responder(s)  using the old CA key until all the certificates issue=
d=20
>>>> =20
>>>>    under the CA' old key for which the OCSP Responder(s) are=20
>>>> =20
>>>>    authoritative  have expired.
>>>> =20
>>>> =20
>>>> =20
>>>> 3. OCSP Responder key rollover
>>>> =20
>>>> =20
>>>> =20
>>>>    When an OCSP Responder performs a key rollover (asynchronously from=
=20
>>>> =20
>>>>    a CA key rollover), then each CA which has designated an OCSP=20
>>>> =20
>>>>    Responder  SHALL issue a new certificate for that OCSP Responder an=
d=20
>>>> =20
>>>>    for each of its issuing keys which meets the following property:=20
>>>> =20
>>>> =20
>>>> =20
>>>>       - the issuing key has been used to sign at least one certificate=
=20
>>>> =20
>>>>         which  contains an AIA extension designating that OCSP Respond=
er=20
>>>> =20
>>>>         and  that certificate is not yet expired.
>>>> =20
>>>> =20
>>>> =20
>>>>    An OCSP Responder key rollover does not affect the values of the=20
>>>> =20
>>>>    URIs that are placed in the accessLocation field from the target=20
>>>> =20
>>>>    certificates.  One or more OCSP Responder MAY respond to an OCSP=20
>>>> =20
>>>>    request  addressed at a given URI picked from the accessLocation=20
>>>> =20
>>>>    field from a target certificate.  Each OCSP Responder MAY use a=20
>>>> =20
>>>>    different  signing key, as long as it got an OCSP certificate=20
>>>> =20
>>>>    appropriate  for that signing key and for the target certificate.=20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> 31. Second annex being proposed. This annex is important because it=20
>>>> describes the validation of an OCSP response in the past=20
>>>>  which is of a particular importance when validating electronic signat=
ures.
>>>> =20
>>>> =20
>>>> =20
>>>> Response processing by an OCSP client
>>>> =20
>>>> =20
>>>> =20
>>>>    OCSP responses can be verified at the current time by an OCSP clien=
t=20
>>>> =20
>>>>    when receiving a response, whereas old responses can be verified at=
=20
>>>> =20
>>>>    a time in the past by a verifier.  The algorithm below addresses=20
>>>> =20
>>>>    both cases.
>>>> =20
>>>> =20
>>>> =20
>>>>    Prior to processing a basic response, OCSP clients MUST determine=20
>>>> =20
>>>>    the checking time, which may be either the current time or a time=20
>>>> =20
>>>>    in the past.
>>>> =20
>>>> =20
>>>> =20
>>>>    OCSP clients or verifiers SHALL check if the response contains=20
>>>> =20
>>>>    responseExtensions.  If such an extension is found and is recognize=
d,=20
>>>> =20
>>>>    it MUST be processed.  If such a critical extension is found and=20
>>>> =20
>>>>    is not recognized, the whole OCSP response MUST be considered as=20
>>>> =20
>>>>    invalid.
>>>> =20
>>>> =20
>>>> =20
>>>>    If the checking time is the current time, and if a nonce extension=20
>>>> =20
>>>>    has been used in the request and is recognized (see section 4.5.1),=
=20
>>>> =20
>>>>    OCSP clients MUST check whether the same nonce is present in the=20
>>>> =20
>>>>    response.  If the nonce is not present or is different, then the=20
>>>> =20
>>>>    OCSP response MUST be discarded.
>>>> =20
>>>> =20
>>>> =20
>>>>    Only the single response(s) which are/is of interest SHALL be=20
>>>> =20
>>>>    checked.
>>>> =20
>>>> =20
>>>> =20
>>>> STEP 1
>>>> =20
>>>> =20
>>>> =20
>>>>    OCSP clients or verifiers SHALL verify that the certificate=20
>>>> =20
>>>>    identified  in a single response is of interest.  Otherwise,  proce=
ed=20
>>>> =20
>>>>    to step 3.
>>>> =20
>>>> =20
>>>> =20
>>>>    If the certificate status included in a single certificate response=
=20
>>>> =20
>>>>    is "unknown", then the revocation status of that certificate is=20
>>>> =20
>>>>    "unknown",  and proceed to step 3.
>>>> =20
>>>> =20
>>>> =20
>>>>    If the certificate status from the single certificate response is=20
>>>> =20
>>>>    either  "good" or "revoked", OCSP clients or verifiers SHALL check=20
>>>> =20
>>>>    that the checking time is within the validity period of the target=20
>>>> =20
>>>>    certificate.  If it is not the case, then the revocation status of=20
>>>> =20
>>>>    that certificate is "unknown" and proceed to step 3.
>>>> =20
>>>> =20
>>>> =20
>>>>    If the checking time is the current time, and if a nonce has been=20
>>>> =20
>>>>    used in the request, then proceed to step 2.
>>>> =20
>>>> =20
>>>> =20
>>>>    If the checking time is the current time, and if no nonce has been=20
>>>> =20
>>>>    used in the request, OCSP clients MUST check that the producedAt
>>>> =20
>>>>    field is within a time window that is "close enough" to the current=
=20
>>>> =20
>>>>    time.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    Note: the notion of "close enough" is a local matter.  It can be se=
t=20
>>>> =20
>>>>          to a few minutes to allow for small UTC time differences=20
>>>> =20
>>>>          between  the client and the server or to a few hours in case=20
>>>> =20
>>>>          the  server is producing pre-computed responses.
>>>> =20
>>>> =20
>>>> =20
>>>>    If the checking time is a time in the past, verifiers MUST check=20
>>>> =20
>>>>    that the producedAt field is in accordance with the verification=20
>>>> =20
>>>>    rules (e.g. close and/or after the date of a time-stamp token).
>>>> =20
>>>> =20
>>>> =20
>>>>    In addition, if the nextUpdate field is present, OCSP clients MUST=20
>>>> =20
>>>>    check that the time which is indicated is greater than the checking=
=20
>>>> =20
>>>>    time,  otherwise the single response MUST be discarded.
>>>> =20
>>>> =20
>>>> =20
>>>>    If checks are successful, then OCSP clients MUST process the=20
>>>> =20
>>>>    singleExtensions  field, if it is present.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    If the criticality flag is set and the extension is not understood,=
=20
>>>> =20
>>>>    then the status of the certificate shall be "unknown" and proceed t=
o=20
>>>> =20
>>>>    step 3.  Otherwise,  proceed to step 2.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    If the extension is understood, then the extension MUST be=20
>>>> =20
>>>>    processed.  According to its content proceed either to step 2 or to=
=20
>>>> =20
>>>>    step 3.=20
>>>> =20
>>>> =20
>>>> =20
>>>> STEP 2
>>>> =20
>>>> =20
>>>> =20
>>>>    OCSP clients or verifiers MUST build and verify a certification pat=
h=20
>>>> =20
>>>>    for that certificate up to a trusted root, so that they have the=20
>>>> =20
>>>>    knowledge of the CA public key value that was used to sign the=20
>>>> =20
>>>>    target  certificate.  The revocation status of each certificate of=20
>>>> =20
>>>>    that certification path (except the target certificate) SHALL be=20
>>>> =20
>>>>    checked.
>>>> =20
>>>> =20
>>>> =20
>>>>    If no path can be built or if one of the certificates of the path i=
s=20
>>>> =20
>>>>    revoked,  then the revocation status of that certificate is "unknow=
n",=20
>>>> =20
>>>>    and proceed to step 3.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    If the certification path (except the target certificate) is valid,=
=20
>>>> =20
>>>>    then two cases need to be considered:
>>>> =20
>>>> =20
>>>> =20
>>>>    a) If the responderID matches with the name or the key from the CA=20
>>>> =20
>>>>       which has issued the target certificate, then check whether the=20
>>>> =20
>>>>       OCSP  response is signed by the same key that was used to sign=20
>>>> =20
>>>>       the  target certificate.
>>>> =20
>>>> =20
>>>> =20
>>>>              If  it is the case, then the revocation status of that=20
>>>> =20
>>>>              certificate  as indicated in the certStatus field is=20
>>>> =20
>>>>              accepted  and proceed to step 3.
>>>> =20
>>>> =20
>>>> =20
>>>>              If  it is not the case, then the revocation status of tha=
t=20
>>>> =20
>>>>              certificate  is "unknown" and proceed to step 3.
>>>> =20
>>>> =20
>>>> =20
>>>>    b) If the responderID does not match with the name or the key from=20
>>>> =20
>>>>       the CA which has issued the target certificate, then it indicate=
s=20
>>>> =20
>>>>       the name or the key from an OCSP Responder.  Check whether there=
=20
>>>> =20
>>>>       exists a local rule which applies to this target certificate to=20
>>>> =20
>>>>       verify  that the signature of the BasicOCSPResponse is valid for=
=20
>>>> =20
>>>>       that  single response.  If this rule exists, it SHALL be followe=
d.=20
>>>> =20
>>>> =20
>>>> =20
>>>>       Otherwise  check whether there is an OCSP certificate (i.e. whic=
h=20
>>>> =20
>>>>       has both the ocspSigning OID in the extended key usage extension=
=20
>>>> =20
>>>>       and the digitalSignature bit in the key usage extension) signed=20
>>>> =20
>>>>       by the same key that was used to sign the target certificate.=20
>>>> =20
>>>>       This  certificate MUST be present in the certs field from the=20
>>>> =20
>>>>       BasicOCSPResponse. =20
>>>> =20
>>>> =20
>>>> =20
>>>>           If  such certificate is not found or is invalid, then the=20
>>>> =20
>>>>           revocation  status of that certificate is "unknown" and=20
>>>> =20
>>>>           proceed  to step 3.
>>>> =20
>>>> =20
>>>> =20
>>>>           If  such certificate exists and if the checking time is=20
>>>> =20
>>>>           within  the validity period of this certificate, then it MUS=
T=20
>>>> =20
>>>>           be  verified whether the OCSP response can be verified using=
=20
>>>> =20
>>>>           the  public key that is present in the OCSP Certificate.=20
>>>> =20
>>>> =20
>>>> =20
>>>>              If  it is not the case, then the revocation status of tha=
t=20
>>>> =20
>>>>              certificate  is "unknown" and proceed to step 3.
>>>> =20
>>>> =20
>>>> =20
>>>>              If  it is the case, then it MUST be verified that the OCS=
P=20
>>>> =20
>>>>              Certificate  has not been revoked.
>>>> =20
>>>> =20
>>>> =20
>>>>      If one of these conditions is met, then the status for the target=
=20
>>>> =20
>>>>      certificate  as indicated in the certStatus field is accepted,=20
>>>> =20
>>>>      otherwise  the revocation status is "unknown".
>>>> =20
>>>> =20
>>>> =20
>>>> STEP 3
>>>> =20
>>>> =20
>>>> =20
>>>>    If there exists another single certificate status response for a=20
>>>> =20
>>>>    target  certificate that is of interest, then proceed to step 1.=20
>>>> =20
>>>>    Otherwise  the basic response is now processed.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> 32. Third annex being proposed. This annex is important because it pro=
vides=20
>>>> guidance on how to build an OCSP responder in the three cases.=20
>>>>  Many text portions are similar, but three full texts are provided in =
order=20
>>>> to provide a better clarity for each of the three cases.
>>>> =20
>>>> =20
>>>> =20
>>>> 1. Request processing by OCSP servers
>>>> =20
>>>> =20
>>>> =20
>>>>    The behavior of an OCSP server will be different whether the OCSP=20
>>>> =20
>>>>    server is a CA acting as an OCSP responder, is an OCSP Responder=20
>>>> =20
>>>>    which  received a delegation from one or more CAs, or is a locally=20
>>>> =20
>>>>    trusted  Responder.
>>>> =20
>>>> =20
>>>> =20
>>>> 1.1. Processing by a CA acting as an OCSP responder
>>>> =20
>>>> =20
>>>> =20
>>>>    The OCSP responder SHALL maintain a list of entries. Each entry=20
>>>> =20
>>>>    SHALL  contain:
>>>> =20
>>>> =20
>>>> =20
>>>>      - the URI associated to the OCSP responder, from which the OCSP=20
>>>> =20
>>>>        requests  are received,=20
>>>> =20
>>>> =20
>>>> =20
>>>>      - the DN from a CA,
>>>> =20
>>>> =20
>>>> =20
>>>>      - an issuing public key from a CA,
>>>> =20
>>>> =20
>>>> =20
>>>>      - the method(s) used to know for which subset of certificates=20
>>>> =20
>>>>        issued  by the CA it is responsible for,=20
>>>> =20
>>>> =20
>>>> =20
>>>>      - the method(s) used to obtain the revocation status of that=20
>>>> =20
>>>>        subset  of certificates issued under that CA issuing public key=
,=20
>>>> =20
>>>>        and
>>>> =20
>>>> =20
>>>> =20
>>>>      - the method used to gain access and sign with the private key=20
>>>> =20
>>>>        corresponding  to the issuing public key.
>>>> =20
>>>> =20
>>>> =20
>>>>    For a given URI value, the OCSP responder SHALL only use one CA=20
>>>> =20
>>>>    key pair value.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    When it receives an OCSP request on that URI, the OCSP responder=20
>>>> =20
>>>>    SHALL handle exceptions according to section 2.3.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    If the OCSP request contains the name of a requestor, the OCSP=20
>>>> =20
>>>>    responder  SHALL verify whether there exists a locally defined rule=
=20
>>>> =20
>>>>    which  regulates access control.  If this rule exists, it SHALL be=20
>>>> =20
>>>>    followed.
>>>> =20
>>>> =20
>>>> =20
>>>>    Then, for each target certificate, the OCSP responder SHALL verify=20
>>>> =20
>>>>    whether both the hash of the issuer's DN and the hash of the issuer=
=20
>>>> =20
>>>>    public key which are present in the request are eligible to a=20
>>>> =20
>>>>    locally  defined rule which indicates that the OCSP responder is=20
>>>> =20
>>>>    responsible  to provide the revocation status of that target=20
>>>> =20
>>>>    certificate.  If this rule exists, it SHALL be followed.
>>>> =20
>>>> =20
>>>> =20
>>>>    Otherwise,  the OCSP responder SHALL determine whether it is=20
>>>> =20
>>>>    responsible  to provide the revocation status of that target=20
>>>> =20
>>>>    certificate  according to the following rule.
>>>> =20
>>>> =20
>>>> =20
>>>>    For each target certificate, the OCSP responder SHALL verify whethe=
r=20
>>>> =20
>>>>    both the hash of the issuer's DN and the hash of the issuer public=20
>>>> =20
>>>>    key which are present in the request match respectively with the DN=
=20
>>>> =20
>>>>    and the hash of the public key of contained in an entry from the=20
>>>> =20
>>>>    list of entries maintained by this OCSP responder.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    When there is no match, then the OCSP responder SHALL indicate the=20
>>>> =20
>>>>    "unknown"  status and proceed with the next target certificate from=
=20
>>>> =20
>>>>    the OCSP request.
>>>> =20
>>>> =20
>>>> =20
>>>>    When there is a match, then the OCSP responder SHALL use the serial=
=20
>>>> =20
>>>>    number of the target certificate that is present in the request and=
=20
>>>> =20
>>>>    determine  the revocation status of that certificate according to=20
>>>> =20
>>>>    the method(s) defined in the entry.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    When the revocation status is provided by the server using a real=20
>>>> =20
>>>>    time access to a database of revocation statuses of issued=20
>>>> =20
>>>>    certificates,  then the thisUpdate field SHALL be present in the
>>>> =20
>>>>    SingleResponse  response whereas the nextUpdate field SHALL be=20
>>>> =20
>>>>    missing.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    Otherwise,  both the thisUpdate and the nextUpdate fields SHALL be=20
>>>> =20
>>>>    present in the SingleResponse.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    The time at which this response will be signed MUST be indicated in=
=20
>>>> =20
>>>>    the producedAt field from the SingleResponse.
>>>> =20
>>>> =20
>>>> =20
>>>>    If a singleRequestExtensions is present in the request it MUST be=20
>>>> =20
>>>>    processed.
>>>> =20
>>>> =20
>>>> =20
>>>>    If there is another target certificate present in the request, it=20
>>>> =20
>>>>    SHALL be processed in the same way.
>>>> =20
>>>> =20
>>>> =20
>>>>    If a requestExtensions is present in the request it MUST be=20
>>>> =20
>>>>    processed.
>>>> =20
>>>> =20
>>>> =20
>>>>    The OCSP response MUST be signed using the CA issuing private key.
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> 1.2. Processing by an OCSP Responder
>>>> =20
>>>> =20
>>>> =20
>>>>    For each CA from which the OCSP Responder has received a delegation=
,=20
>>>> =20
>>>>    the OCSP Responder SHALL maintain a list of entries.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    Each entry SHALL contain:
>>>> =20
>>>> =20
>>>> =20
>>>>      - the URI associated to this OCSP Responder, from which the OCSP=20
>>>> =20
>>>>        requests  are received,=20
>>>> =20
>>>> =20
>>>> =20
>>>>      - the DN from a CA,
>>>> =20
>>>> =20
>>>> =20
>>>>      - an issuing public key from a CA,
>>>> =20
>>>> =20
>>>> =20
>>>>      - the method(s) used to know for which subset of certificates=20
>>>> =20
>>>>        issued  by the CA it is responsible for,=20
>>>> =20
>>>> =20
>>>> =20
>>>>      - the method(s) used to obtain the revocation status of that=20
>>>> =20
>>>>        subset  of certificates issued under that CA issuing public key=
,
>>>> =20
>>>> =20
>>>> =20
>>>>      - an OCSP certificate,=20
>>>> =20
>>>> =20
>>>> =20
>>>>      - the OCSP public key contained in that OCSP certificate, and
>>>> =20
>>>> =20
>>>> =20
>>>>      - the method used to gain access and sign with the OCSP private=20
>>>> =20
>>>>        key  corresponding to that OCSP certificate.
>>>> =20
>>>> =20
>>>> =20
>>>>    For a given URI value, the OCSP Responder SHALL only use one OCSP=20
>>>> =20
>>>>    key pair value.  Therefore there cannot be two entries with the=20
>>>> =20
>>>>    same URI value and a different OCSP public key value.
>>>> =20
>>>> =20
>>>> =20
>>>>    NOTE: a BasicOCSPResponse can only be signed using a single private=
=20
>>>> =20
>>>>          key.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    The OCSP certificate SHALL be signed by the CA issuing private key=20
>>>> =20
>>>>    which  corresponds to the issuing CA public key that is in this=20
>>>> =20
>>>>    entry.
>>>> =20
>>>> =20
>>>> =20
>>>>    When it receives an OCSP request, the OCSP responder SHALL handle=20
>>>> =20
>>>>    exceptions  according to section 2.3.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    If the OCSP request contains the name of a requestor, the OCSP=20
>>>> =20
>>>>    responder  SHALL verify whether there exists a locally defined rule=
=20
>>>> =20
>>>>    which  regulates access control.  If this rule exists, it SHALL be=20
>>>> =20
>>>>    followed.
>>>> =20
>>>> =20
>>>> =20
>>>>    For each target certificate, the OCSP Responder SHALL verify=20
>>>> =20
>>>>    whether both the hash of the issuer's DN and the hash of the issuer=
=20
>>>> =20
>>>>    public key which are present in the OCSP request match with those=20
>>>> =20
>>>>    from an entry.
>>>> =20
>>>> =20
>>>> =20
>>>>    When there is no match, then the OCSP Responder SHALL indicate the=20
>>>> =20
>>>>    "unknown"  status and proceed with the next target certificate from=
=20
>>>> =20
>>>>    the OCSP request.
>>>> =20
>>>> =20
>>>> =20
>>>>    When there is a match, the OCSP Responder SHALL use the serial=20
>>>> =20
>>>>    number of the target certificate this is present in the OCSP=20
>>>> =20
>>>>    request to determine the revocation status of that certificate=20
>>>> =20
>>>>    according to the method(s) indicated in the entry.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    When the revocation status is provided by the server using a real=20
>>>> =20
>>>>    time access to a database of revocation statuses of issued=20
>>>> =20
>>>>    certificates,  then the thisUpdate field SHALL be present in the
>>>> =20
>>>>    SingleResponse  response whereas the nextUpdate field SHALL be=20
>>>> =20
>>>>    missing.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    Otherwise,  both the thisUpdate and the nextUpdate fields SHALL be=20
>>>> =20
>>>>    present in the SingleResponse.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    The time at which this response will be signed MUST be indicated in=
=20
>>>> =20
>>>>    the producedAt field from the SingleResponse.
>>>> =20
>>>> =20
>>>> =20
>>>>    If a singleRequestExtensions is present in the request it MUST be=20
>>>> =20
>>>>    processed.
>>>> =20
>>>> =20
>>>> =20
>>>>    If there is another target certificate present in the request, it=20
>>>> =20
>>>>    SHALL be processed in the same way.
>>>> =20
>>>> =20
>>>> =20
>>>>    If a requestExtensions is present in the request it SHALL be=20
>>>> =20
>>>>    processed.
>>>> =20
>>>> =20
>>>> =20
>>>>    The OCSP response MUST be signed using the OCSP private key.
>>>> =20
>>>> =20
>>>> =20
>>>>    Unless there is a local rule which states differently, for every=20
>>>> =20
>>>>    target  certificate which matches both with the hash of a CA DN and=
 an=20
>>>> =20
>>>>    issuing  public key from an entry, the OCSP certificate of that ent=
ry=20
>>>> =20
>>>>    SHALL be placed in the certs field.
>>>> =20
>>>> =20
>>>> =20
>>>>    It may happen, that none of the target certificates from the OCSP
>>>> =20
>>>>    request  matches both with the hash of a CA DN and an issuing publi=
c=20
>>>> =20
>>>>    key from an entry.  In that case and unless a local rule states=20
>>>> =20
>>>>    differently,  the certs field from the BasicOCSPResponse SHOULD be=20
>>>> =20
>>>>    kept empty (to limit the disclose of the names of the CAs from whic=
h=20
>>>> =20
>>>>    the OCSP Responder received a delegation from).
>>>> =20
>>>> =20
>>>> =20
>>>> 1.3. Processing by a locally trusted Responder
>>>> =20
>>>> =20
>>>> =20
>>>>    For each CA for which the locally trusted Responder is=20
>>>> =20
>>>>    authoritative,  the OCSP Responder SHALL maintain a list of entries=
.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    Each entry SHALL contain:
>>>> =20
>>>> =20
>>>> =20
>>>>      - the URI associated to this OCSP Responder, from which the OCSP=20
>>>> =20
>>>>        requests  are received,=20
>>>> =20
>>>> =20
>>>> =20
>>>>      - the DN from a CA,
>>>> =20
>>>> =20
>>>> =20
>>>>      - an issuing public key from a CA,
>>>> =20
>>>> =20
>>>> =20
>>>>      - the method(s) used to know for which subset of certificates=20
>>>> =20
>>>>        issued  by the CA it is responsible for,=20
>>>> =20
>>>> =20
>>>> =20
>>>>      - the method(s) used to obtain the revocation status of that=20
>>>> =20
>>>>        subset  of certificates issued under that CA issuing public key=
,
>>>> =20
>>>> =20
>>>> =20
>>>>      - the method used to gain access to the private key in order to=20
>>>> =20
>>>>        sign the OCSP response.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    For a given URI value, the OCSP Responder SHALL only use one privat=
e=20
>>>> =20
>>>>    key.  Therefore  there cannot be two entries with the same URI valu=
e=20
>>>> =20
>>>>    and a different method to gain access to the appropriate private ke=
y.
>>>> =20
>>>> =20
>>>> =20
>>>>    NOTE: a BasicOCSPResponse can only be signed using a single private=
=20
>>>> =20
>>>>          key.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    When it receives an OCSP request, the OCSP responder SHALL handle=20
>>>> =20
>>>>    exceptions  according to section 2.3.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    If the OCSP request contains the name of a requestor, the OCSP=20
>>>> =20
>>>>    responder  SHALL verify whether there exists a locally defined rule=
=20
>>>> =20
>>>>    which  regulates access control.  If this rule exists, it SHALL be=20
>>>> =20
>>>>    followed.
>>>> =20
>>>> =20
>>>> =20
>>>>    For each target certificate, the OCSP Responder SHALL verify=20
>>>> =20
>>>>    whether both the hash of the issuer's DN and the hash of the issuer=
=20
>>>> =20
>>>>    public key which are present in the OCSP request match with those=20
>>>> =20
>>>>    from an entry.
>>>> =20
>>>> =20
>>>> =20
>>>>    When there is no match, then the OCSP Responder SHALL indicate the=20
>>>> =20
>>>>    "unknown"  status and proceed with the next target certificate from=
=20
>>>> =20
>>>>    the OCSP request.
>>>> =20
>>>> =20
>>>> =20
>>>>    When there is a match, the OCSP Responder SHALL use the serial=20
>>>> =20
>>>>    number of the target certificate this is present in the OCSP=20
>>>> =20
>>>>    request to determine the revocation status of that certificate=20
>>>> =20
>>>>    according to the method(s) indicated in the entry.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    When the revocation status is provided by the server using a real=20
>>>> =20
>>>>    time access to a database of revocation statuses of issued=20
>>>> =20
>>>>    certificates,  then the thisUpdate field SHALL be present in the
>>>> =20
>>>>    SingleResponse  response whereas the nextUpdate field SHALL be=20
>>>> =20
>>>>    missing.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    Otherwise,  both the thisUpdate and the nextUpdate fields SHALL be=20
>>>> =20
>>>>    present in the SingleResponse.=20
>>>> =20
>>>> =20
>>>> =20
>>>>    The time at which this response will be signed MUST be indicated in=
=20
>>>> =20
>>>>    the producedAt field from the SingleResponse.
>>>> =20
>>>> =20
>>>> =20
>>>>    If a singleRequestExtensions is present in the request it MUST be=20
>>>> =20
>>>>    processed.
>>>> =20
>>>> =20
>>>> =20
>>>>    If there is another target certificate present in the request, it=20
>>>> =20
>>>>    SHALL be processed in the same way.
>>>> =20
>>>> =20
>>>> =20
>>>>    If a requestExtensions is present in the request it SHALL be=20
>>>> =20
>>>>    processed.
>>>> =20
>>>> =20
>>>> =20
>>>>    The OCSP response MUST be signed using the OCSP private key.
>>>> =20
>>>> =20
>>>> =20
>>>>    The certs field may contain no, one or several OCSP certificates=20
>>>> =20
>>>>    according to local rules followed by the locally trusted Responder.
>>>> =20
>>>> =20
>>>> =20
>>>  =20
>>>=20
>>> =20
>>> =20
>>> Not broken.
>>> =20
>>>=20
>>> =20
>>> =20
>>> /Stefan
>>> =20
>>>=20
>>> =20
>>>  =20
>>>> =20
>>>> =20
>>>> =20
>>>>=20
>>>> =20
>>>> =20
>>>> =20
>>>> =20
>>>> End of comments
>>>> =20
>>>> =20
>>>>=20
>>>>  Denis
>>>> =20
>>>> =20
>>>> =20
>>> =20
>> =20
>> =20
>> =20
> =20
> =20
> =20
> _______________________________________________ pkix mailing list=20
> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix=20



--B_3444825885_27912951
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


Denis,

<=
div>Your comments that were given during the WGLC has been responded to.
I's just not to your satisfaction.

As your f=
ollowup questions took quite some time, I was not aware that you were not ha=
ppy with responses to your issues when we prepared the publication request t=
o the IESG.
I'm still struggling to get time to respond to your la=
st mail. But it will happen before the end of the week.

=

/Stefan

From:  D=
enis Pinkas <denis.pinkas@bull.net=
>
Date:  Wednesday, February=
 27, 2013 3:38 PM
To:  Sean Turner =
<turners@ieca.com>
Cc:  <pkix@iet=
f.org>, Stefan Santesson <stef=
an@aaa-sec.com>
Subject:  Re=
: [pkix] AD review of draft-ietf-pkix-rfc2560bis


  
    
  
  

    
Sean,

      

      You said:

      

    

    
When we
      close on #1, I'll whack the LC button.
      

      

      spt
    

    

    May I  recall you that I addressed comments during the WGLC which
    have not been addressed 

    to my satisfaction and that Stefan sent me a private answer on
    February 11, 2013 which is copied below

    

    At this time, Stefan has not yet send me a reply.

    

    Denis

    

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=

    
Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC

      

      Denis,

    


    

    
I will review your comments.

    
Unfortunately I won't be able to do so this week.

    


    

    
This document has already been sent to the IESG with a request
      for publication.

    
I will check in what way the comments will be handled.

    


    

    
/Stefan

    


    

    
      
From: 
        Denis Pinkas <denis.pinka=
s@bull.net>

        Date:  Monday, February
        11, 2013 3:18 PM

        To:  Stefan Santesson
        <stefan@aaa-sec.com><=
br>
        Cc:  pkix <pkix@ietf.org>

        Subject:  Re: [pkix]
        Review of 2560-bis draft 8. Answer to WGLC

      

      


      

      

        

          

            

                
Stefan,

                
 

                
I have
                    finally reviewed your disposition of comments. I
                    have used draft 13.

                
 

                
I will
                    not address the commen=
ts in
                    sequence, but I will consider four categories:

                
 

                
Category
                      1) Some <=
span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB">comments
                      which seem to be solved. Yes indeed,
                    they may be a few of them !

                
 

                
Category
                      2) Some <=
span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB">comments
                      which might possibly be solved at
                    the WG level.

                
 

                
Category
                      3) Some <=
span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB">comments
                      that I will address at the IETF last
                    call level, rather than the WG last call level,
                    since I disagree 

                    that it is “new ways to say the same thing”=
 and it
                    is likely to be a waste of time for both of us to
                    argue again at the WG level 

                    (these comments are commented as “not broken̶=
1;).

                
 

                
Category
                      4) Some typos and editorials found while
                    reading draft 13.

                
 

                
 

                
CATEGORY
                      1

                
 

                
Comment
                      4 (was editorial).

                
 

                
Comment
                      5.

                
 =


                
Comment
                      6. 

                
 

                
Comment
                      19. Solved, since R=
20;unknown” seems
                    now to be also allowed for non-issued certificates 
=

                    (even if the OCSP responder is using a direct access
                    to the certificate database). See comment 8.=


                
 

                
Comment
                      13: Acceptable, since the text uses ̶=
0;MAY”.<=
o:p>

                
 

                
Comment
                      18. 

                
 

                
Comment
                      22.

                
 

                
Comment
                      23.

                
 

                
Comment
                      28.

                
 

                
CATEGORY
                      1

                
 

                
Comment
                      8: You have changed the meaning of the
                    revoked state in a way that is not what I requested.
                    

                
 

                
The
                    original text was:

                
 

                
   The
                      "revoked" state indicates that the certificate has
                      been revoked

                
   (either
                      permanantly or temporarily (on hold)).

                
 

                
The new
                    text is:

                
 =


                
   The =
"revoked" state indicates that the certificate has been revoked

                
   eith=
er permanently or temporarily on hold (i.e. the revocation reason=


                
   is c=
ertificateHold).

                
 

                
By
                    doing this, you do not allow any other case in the
                    future to have a temporary revocation: “tempo=
rarily
on

                      hold” 

                    is not the same as “tempo=
rarily

                      revoked”.<=
/span>

                
 

                
I
                    propose the following rewording: 
=

                
 

                
   The
                      "revoked" state indicates that the certificate has
                      been revoked 

                
   eith=
er permanently or temporarily (e.g. placed on hold).
                
 

                
The way
                    the text from draft 13 is now written seems to allow
                    using either ̶=
0;unknown” or R=
20;revoked” for
                    non-issued certificates. 

                    If this is the intent, then the good news is that
                    this does not come anymore into conflict with the
                    French rules which apply for 

                    the Administration since OCSP responders from CAs
                    used by the French Ministries having a direct access
                    to the database 

                    of issued certificates will be able to use ̶=
0;unknown̶=
1;,
                    rather than ̶=
0;revoked” and
                    the reason code ̶=
0;onhold”.

                
 

                
However,

                    the current text is still mandating the use of <=
b style=3D"mso-bidi-font-weight: normal">Exte=
nded
                      Revoked Definition, but
                    the rational for its need it is very poor. 

                    As I have said on the PKIX list, the fact that the
                    revocation date is January 1rst, 1970 is fully
                    sufficient to know that we are in that 

                    very special case, and you have not provided a
                    rational to say the contrary.

                
 

                
So we
                    could get rid of it, … but the text from section
                    4.4.8 states:

                
 

                
   This=
 extension MAY be present in other responses to signal that the

                
   resp=
onder implements the extended revoked definition in section 2.2.<=
/span>

                
 

                
I have
                    difficulties to understand what is really meant
                    there (“other responses” ?), since the text=
 states:

                
 

                
   This=
 extension indicates that the responder supports the extended

                
   defi=
nition of the "revoked" status to also include non-issued<=
/b>

                
   cert=
ificates according to section 2.2.

                
 

                
Since
                    both “unknown” and revoked” can be us=
ed, it would be
                    desirable to be able to include the same extension
                    in both cases, 

                    but in that case that extension should be renamed.=


                
 

                
I would
                    propose to rename it: "non-=
issued
                      certificate”
                    which means that the associated CA has no record of
                    ever having issued 

                    a certificate with the certificate serial number in
                    the request (I still consider it as unnecessary in
                    the case of “revoked”, but it would be 
=

                    very useful in the case of “unknown”). Of c=
ourse,
                    the text from section 4.4.8 would need to be
                    revised.

                
 

                
I
                    propose the following:

                
 

                
4.4.8  Non-i=
ssued certificate extension

                
 

                
   This extension MUST be included in the OC=
SP response when the OCSP 

                
   responder knows that the CA identified in the request has no record 

                
   of ever having issued a certificate with the certificate serial =


                
   number indicated in the request.

                
 

                
   Clients do not have to parse this extensi=
on in order to determine 

                
   the status of certificates in responses.

                
 

                
   This extension is identified by the objec=
t identifier id-pkix-ocsp-

                
   non-=
issued-cert.

                
 

                
     id-pkix-ocsp-non-issued-cert =
OBJECT IDENTIFIER ::=3D {id-pkix-ocsp 9}

                
 

                
   The value of the extension SHALL be NULL.=
 This extension MUST NOT be

                
   mark=
ed critical.

                
 

                
Then
                    the text on page 8 would need to be rearranged.

                
 

                
The
                    current text is:

                
 

                
   This=
 state MAY also be returned if the

                
   asso=
ciated CA has no record of ever having issued a certificate with<=
/span>

                
   the =
certificate serial number in the request, using any current or

                
   prev=
ious issuing key (referred to as a "non-issued" certificate in

                
   this=
 document).

                
 

                
   The "unknown" state indicates that the re=
sponder doesn't know about

                
   the =
certificate being requested.

                
 

                
   NOTE: The "revoked" state for known non-i=
ssued certificate serial

                
    =
     numbers is allowed in order to reduce the ri=
sk of relying

                
    =
     parties using CRLs as a fall back mechanism,=
 which would be

                
    =
     considerably higher if an "unknown" response=
 was returned.

                
 

                
   When a responder responds revoked to a st=
atus request for a non-

                
   issu=
ed certificate, the responder MUST include the extended revoked

                
   defi=
nition response extension (section 4.4.8) in the response,=


                
   indi=
cating that the OCSP responder supports the extended definition

                
   of r=
evoked state to also cover non-issued certificates. In addition,<=
/span>

                
   the =
SingleResponse related to this non-issued certificate;=


                
 

                
    - MUST provide the revocation reaso=
n certificateHold (6),

                
 

                
    - MUST specify the revocationTime J=
anuary 1, 1970, and;

                
 

                
    - MUST NOT include a CRL References extension (section 4.4.2) or any=


                
    =
  CRL Entry Extensions (section 4.4.5). 
                
 

                
Proposed

                    text for a replacement:

                
 

                
   The =
"unknown" state indicates that the responder doesn't know about

                
   the =
certificate being requested.

                
 

                
   If the OCSP responder knows that CA ident=
ified in the request has 

                
   no record of ever having issued a certificate with the certificate 

                
   serial number in the request, using any current or previous issuing 

                
   key (referred to as a "non-issued" certificate in this document), 

                
   the OCSP responder SHALL respond either “revoked “ or “un=
known”.

                
 

                
   Note: The "revoked" state for known non-i=
ssued certificate serial 

                
   numbers is allowed in order to reduce the risk of relying parties 

                
   using CRLs as a fall back mechanism, which would be possible when 

                
   the "unknown" response is returned.

                
 

                
   When a responder responds revoked or unkn=
own to a status request 

                
   for a non-issued certificate, the responder MUST include the 

                
   non-issued certificate extension (see section 4.4.8) in the 

                
   response. 

                
 

                
   When a responder responds revoked to a st=
atus request for a non-

                
   issu=
ed certificate, in addition, the responder:

                
 

                
    - MUST provide the revocation reaso=
n certificateHold (6),

                
 

                
    - MUST specify the revocationTime J=
anuary 1, 1970, and;

                
 

                
    - MUST NOT include a CRL References=
 extension (section 4.4.2) or any

                
    =
  CRL Entry Extensions (section 4.4.5).
                
 

                
Finally,

                    the last bullet on page 4 should be reworded:

                
 

                
Current
                    text:

                
 

                
    =
  o Section 4.4.8 specifies a new extension that indicates that =
the

                
    =
     responder supports the extended use of the "=
revoked" response

                
    =
     for non-issued certificates defined in secti=
on 2.2.

                
 =


                
Proposed

                    replacement text:

                
 

                
    =
  o  Section 4.4.8 sp=
ecifies a new extension that indicates that 

                
    =
     the OCSP responder knows that CA identi=
fied in the request 

                
    =
     has no record of ever having issued a c=
ertificate with the 

                
    =
     certificate serial number present in th=
e request, as defined 

                
    =
     in section 2.2.
                
 

                
Comment
                      9: Solved, if the comment above may be
                    solved.

                
 

                
Comment
                      20:  This

                    comment is preliminary classified by you as “not
                    broken”. However, since you asked: “If you =
don’t
                    replace 4.2.2.3,

                    then what really are you missing ?”, I will provi=
de
                    you with an answer.

                
 

                
This is
                    the wrong way to state the question. Providing an
                    ASN.1 syntax as in 4.2.1 is not enough: the use of
                    every parameter 

                    MUST be explained using English words. So if you
                    explain the use of every parameter after the
                    description of the ASN.1 syntax 

                    in section 4.2.1. then section 4.2.2.3 is no more
                    needed and thus can be deleted.

                
 

                
The
                    answer to your question “what is really missing&#=
8221; is
                    a description of the use of every parameter listed
                    in the ASN.1 in section 4.2.1

                
 

                
Comment
                      21.

                
 

                
While I
                    can agree in general with the intent of the text, I
                    do not understand the first sentence of the Note
                    which speaks of “CA key rollover” 

                    and is copied below:

                
 

                
   Note=
: CA key rollover is not prohibited when issuing a certificate

                
    =
     for an authorized responder for backwards co=
mpatibility with

                
    =
     RFC 2560 [RFC2560]. That is, it is not prohi=
bited to issue a

                
    =
     certificate for an authorized responder usin=
g a different

                
    =
     issuing key than the key used to issued the =
certificate being

                
    =
     checked for revocation. However, such practi=
ce is strongly

                
    =
     discouraged since clients are not required t=
o recognize a

                
    =
     responder with such certificate as an author=
ized responder.

                
 

                
I would
                    propose to delete it, since it does not add anything
                    and thus to have:

                
 

                
   Note=
: For backwards compatibility with RFC 2560 [RFC2560], it is 

                
    =
     not prohibited to issue a certificate f=
or an authorized 

                
    =
     responder using a different issuing key=
 than the key used to 

                
    =
     issued the certificate being checked fo=
r revocation. 

                
    =
     However, such practice is strongly disc=
ouraged since clients 

                
    =
     are not required to recognize a respond=
er with such 

                
    =
     certificate as an authorized responder.=


                
 

                
Comment
                      24: The ASN.1 module in annex B.1 is
                    still wrong, since it does not define NoCheck. 

                
 

                
Comment
                      26: You asked for explanations. Let me
                    provide you with an example when CRLs are being used
                    by the OCSP responder 

                    in the background. The OCSP responder needs to make
                    sure that the CRL it uses is valid. If it is simply
                    using published CRLs 

                    (i.e. no trusted link with the CA), it needs to make
                    sure that the CA which has issued the CRL has no
                    been revoked.

                
 

                
In France,
                    there is a root CA for the Administration. However,
                    the use of that root CA is optional. Thus a Ministry
                    may have its own root, 

                    but may also have its key certified by the root CA
                    of the Administration. The OCSP responder may use
                    the root CA of the Ministry, 

                    while a relying party may use the root CA of the
                    Administration (or the reverse) to validate the CRL
                    for the target certificate. 

                    Thus the revocation status will be different if the
                    certificate of the CA of the Ministry is revoked by
                    the root CA of the Administration.
                
 

                
CATEGORY
                      3

                
 

                
Comments 2, 3,
                    7, 10, 12, 14, 15, 16, 17, 25 and 27.=


                
 

                
 

                
CATEGORY
                      4

                
 

                
Page 4.
                    The indentation of the bullets in section 1 is not
                    uniform. 

                    Bullets 1, 4, 5 and 9 have problems.<=
/p>
                
 

                
Page 4.
                    The fact that there is now an Annex B.2 dealing with
                    the 2008 ASN.1 syntax is missing. This should be
                    added.

                
 

                
Page
                    10. Change “Se
                      further section 4.2.2.2” into
                    “See

                      further section 4.2.2.2”

                    

                


                  Denis

                  =


                
 

                
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

                      

                    

              

            

            

              
Denis,

              


              

              
Responding
                to your comments below.

              


              

              
However,
                one general remark to make recurring comments easier to
                understand.

              


              

              
The WG
                decided to adopt a minimalistic approach to updating RFC
                2560. That means that 

              
    
                
  1. We don't change anything from RFC 2560 unless it is
                  broken, or the industry clearly need clarifications in
                  order to avoid interoperability issues.
    2. 
                
  2. We retain the document structure of RFC 2560 as much
                  as possible to allow easy comparison of what the
                  changes are in comparison with RFC 2560.
    3. 
              

              


              

              
One can
                always think up more clever ways to write things out in
                words. But that also comes with a risk.

              
The
                current words has been around for a long time and we
                know from experience which words worked to produce
                working implementations, and which did not.

              
Introducing
                new ways to say the same thing may introduce new
                problems and people might disagree on what the new
                perfect wording should be. And this could go on forever.
              


              

              
So when my
                reply is "Not broken", then that is because the current
                wording does not have such problems that is merits a
                change.

              


              

              


              

              


              

              
                
From:
                   Denis Pinkas <denis.pinkas@bull.net>

                  Date:  Sunday,
                  January 20, 2013 5:12 PM

                  To:  Stefan
                  Santesson <stefan@aaa-sec.com>,

                  Stephen Kent <kent@bbn.com>

                  Cc:  pkix <pkix@ietf.org>

                  Subject:  Re:
                  [pkix] Review of 2560-bis draft 8. Answer to WGLC

                

                


                

                

                  

                    
 
                        
Please find 32 comments on
                          draft-ietf-pkix-rfc2560bis

                        
 

                        
1.
                            The document states:

                        
 <Cut away issue 1
                            regarding authorship etc, as it has been
                            responded to separately>

                      

                  

                

              
              


              

              
Responded
                to separately.

              


              

              
                

                  

                    

                        
 
                        
 
                        
2.
                            The current text from section 2 states:

                        
 
                        
2.  Protocol Overview

                        
 

                        
   In lieu of or as a s=
upplement to checking against a periodic CRL, it

                        
   may be necessary to =
obtain timely information regardi=
ng the

                        
   revocation status of=
 a certificate (cf. RFC5280], Section 3.3).

                        
   Examples include hig=
h-value funds transfer or large stock trades.

                        
 

                        
   The Online Certifica=
te Status Protocol (OCSP) enables applications to

                        
   determine the (revoc=
ation) state of an identified certificate. OCSP

                        
   may be used to satis=
fy some of the operational requirements of

                        
   providing more timely revocation information than is =
possible with

                        
   CRLs and may also be=
 used to obtain additional status information. 

                        
 

                        
This text is misleading because readers may t=
hink that OCPS necessarily provides “timely information”.

                        
 

                      

                  

                

              
              


              

              
"may" does
                not mean "necessarily".

              


              

              
                

                  

                    

                        
Proposed text replacement:<=
/pre>
                        
 

                        
   The
                              Online Certificate Status Protocol (OCSP)
                              is a client-server 
=

                        
   protocol

                              which enables applications to obtain the
                              revocation status 

                        
   of
                              one or more certificates either "good",
                              "revoked", or "unknown".

                        
 

                        
   The
                              revocation status may be provided by the
                              server either using a <=
/p>
                        
   real
                              time access to a database of issued
                              certificates, or using a 

                        
   batch
                              access to a database of issued
                              certificates, or using a 

                        
   real
                              time access to a database of revocation
                              statuses of issued 
=

                        
   certificates,

                              or using a batch access to a database of
                              revocation 

                        
   statuses
                              of issued certificates, or using CRLs, or
                              using a 

                        
   combination

                              of base CRLs and delta CRLs.

                        
 

                        
   In
                              the first case, it is possible to obtain
                              timely revocation status 

                        
   information,

                              whereas in the other cases, the freshness
                              of the 

                        
   revocation

                              status is not better than the mechanisms
                              it is based on.

                        
 

                        
 

                      

                  

                

              
              


              

              
Not broken
              


              

              
                

                  

                    

                        
3.
                            The current text from section 2 states:

                        
 

                        
   An OCSP client issue=
s a status request to an OCSP responder and 

                        
   Suspends accept=
ance of the certificate in question until the 

                        
   responder provi=
des a response.

                        
 

                        
   This protocol specif=
ies the data that needs to be exchanged between

                        
   an application check=
ing the status of a certificate and the server

                        
   providing that statu=
s.

                        
 

                        
Thus is insufficient for an overview. More de=
tails are needed to know what the document provides, 
in particular that the request may contain several requests for several cer=
tificates issued by different CAs. 
The possibility of using extensions should also be advertised.

                        
 

                        
Proposed text replacement:<=
/pre>
                        
 

                        
&n=
bsp; 
                            When using OCSP, an OCSP client
                            issues a certificate revocation 

                        
&n=
bsp; 
                            status request to an OCSP responder for
                              one or more certificates 

                        
   issued
                              by the same CA or for one or more
                              certificates issued by =


                        
   different

                              CAs and then suspends acceptance of
                            the certificate(s) 

                        
&n=
bsp; 
                            in question until the responder
                            provides a response.

                        
 

                        
&n=
bsp; 
                            This document specifies the data that
                            needs to be exchanged between=


                        
&n=
bsp; 
                            an application checking the status of
                            a certificate and the server<=
/p>
                        
&n=
bsp; 
                            providing that status.  

                        
 

                        
   OCSP
                              may also provide additional status
                              information using 

                        
   extensions.

                              

                        
 
                        
 
                      

                  

                

              
              


              

              
Not broken
              


              

              
                

                  

                    

                        
4.
                            Page 6. Editorial. Punctuation and a CR/LF
                            are missing.

                        
 
                        
The

                            text states:

                        
 

                        
   3. t=
he request contains the information needed by the responder If

                        
    =
  any one of the prior conditions are not met, the OCSP responde=
r

                        
    =
  produces an error message; otherwise, it returns a definitive<=
o:p>

                        
    =
  response.

                        
 

                        
It

                            should state:

                        
 

                        
   4. t=
he request contains the information needed by the responder.

                        
 

                        
      If any one of the prior=
 conditions are not met, the OCSP responder

                        
    =
  produces an error message; otherwise, it returns a definitive<=
o:p>

                        
    =
  response.

                        
 
                        
 
                      

                  

                

              
              


              

              
Fixed in
                draft 10.

              


              

              
                

                  

                    

                        
5.
                            On page 7, the text states:
                        
 

                        
   All
                              definitive response messages SHALL be
                              digitally signed. The key

                        
   used
                              to sign the response MUST belong to one of
                              the following:

                        
 

                        
   -  the CA who issued the certificate in question
                        
   -  a Trusted Responder whose public k=
ey is trusted by the requester

                        
   -  a CA Designated Responder (Authori=
zed Responder) who holds a

                        
    =
  specially marked certificate issued directly by the CA, indica=
ting

                        
    =
  that the responder may issue OCSP responses for that CA.<=
/o:p>

                        
 

                        
The

                            paragraph is ambiguous on several aspects. 

                        
 

                        
Delegation


                            is addressed in at least three different
                            places, but with different terms and
                            conditions. 

                            If some one picks a sentence in one
                            paragraph rather than another, it will lead
                            to a different conclusion. 

                            RFCs are supposed to be clear.

                        
 
                        
On page 10, the current te=
xt
                            states in section
                            2.6
                              OCSP Signature Authority Delegation states:

                        
 

                        
   The key that signs a
                                certificate's status information need
                                not be the
=

                        
   sam=
e
                              key that signed the certificate. A certificate's issuer

                        
   explicitly

                              delegates OCSP signing authority by
                              issuing a certificate
                        
   containing
                              a unique value for extendedKeyUsage in the
                              OCSP signer's

                        
   certificate.

                              This certificate MUST be issued directly
                              to the

                        
   responder
                              by the cognizant CA.
                        
 

                        
On
                            page 16, there is a section 4.2.2.2 called “=
Authorized Responders” dealing with the same topic. 

                        
 

                        
Section

                            4.2.2.2 states:

                        
 
                        
   The key that signs a
                                certificate's status information need
                                not be the
=

                        
   sam=
e
                              key that signed the certificate. It is necessary however to

                        
   ensure
                              that the entity signing this information
                              is authorized to do
=

                        
   so.&nbs=
p; Therefore,
                              a certificate's issuer MAY either sign the
                              OCSP

                        
   responses

                              itself or it MAY explicitly designate this
                              authority to

                        
   another

                              entity.  =
OCSP


                              signing delegation SHALL be designated by
                              the

                        
   inclusion
                              of id-kp-OCSPSigning in an
                              extendedKeyUsage certificate

                        
   extension

                              included in the OCSP response signer's
                              certificate.&n=
bsp;
                              This

                        
   certificate

                              MUST be issued directly by the CA that
                              issued the

                        
   certificate

                              in question.

                        
 

                        
   The
                              CA SHOULD use the same issuing key to
                              issue a delegation

                        
   certificate

                              as was used to sign the certificate being
                              checked for

                        
   revocation.

                              Systems


                                relying on OCSP responses MUST recognize
                                a

                        
   delegation


                              certificate as being issued by the CA that
                              issued the

                        
   certificate


                              in question only if the delegation
                              certificate and the
=

                        
   certificate


                              being checked for revocation was signed by
                              the same key.

                        
 
                        
The

                            last sentence above in yellow is the key
                            sentence that is missing in the two other
                            sections.

                        
 

                        
Most implementations only support the case wh=
ere the OCSP Responder receives an OCSP certificate that is signed by the sa=
me key 
that was used to sign the target certificate. They do not support the case =
where the OCSP Responder receives an OCSP certificate 
that is signed by a key that is different from the one that was used to sig=
n the target certificate.

                        
 

                        
It
                            is inappropriate to have three sections
                            dealing with the same topic with a slightly
                            different meaning.

                        
 

                        
It
                            is proposed the following.
                        
 

                        
On
                            page 7, after:

                        
 
                        
   -  a CA Designated Responder (Authori=
zed Responder) who holds a

                        
    =
  specially marked certificate issued directly by the CA, indica=
ting

                        
    =
  that the responder may issue OCSP responses for that CA.<=
/o:p>

                        
 
                        
it
                            is proposed to add “(see section 4.2.2.2 for
                              further details)”,
                            so that the reader knows that more details
                            are provided later on.

                        
 
                        
Then we do not need two
                            sections to address delegation which start
                            with the same sentence:
                            

                          

                        


                            “T=
he
                              key that signs a certificate's status
                              information need not be the same key that
                              signed the certificate”.=


                        
 

                        
It
                            is thus proposed to delete section 2.6.

                        
 

                        
Section

                            4.2.2.2 will thus remain the single section
                            providing full details.

                        
 
                        
 

                      

                  

                

              
              


              

              
I have
                added references to section 4.2.2.2 in the quoted
                sections in 2.2 and 2.6.

              
(will be
                included in draft 11)

              


              

              


              

              
                

                  

                    

                        
6. Page 7, the text states:

                        
 
                        
   A de=
finitive response message is composed of:

                        
 

                        
   -  version of the response syntax

                        
   -  name of the responder

                        
   -  responses for each of the certific=
ates in a request

                        
   -  optional extensions

                        
   -  signature algorithm OID=


                        
   -  signature computed across hash of =
the response

                        
 
                        
This

                            description does not fit with the ASN.1
                            syntax which is detailed later on, and in
                            particular:

                        
 
                        
   ResponseData ::=3D SEQUENCE {

                        
      version        &nbs=
p;     [0] EXPLICIT Version DEFAULT v1,

                        
      responderID  &=
nbsp;           Res=
ponderID,

                        
    =
  producedAt   &nb=
sp;           Gener=
alizedTime,

                        
    =
  responses   &nbs=
p;            =
SEQUENCE OF SingleResponse,

                        
    =
  responseExtensions   =
[1] EXPLICIT Extensions OPTIONAL }

                        
 
                        
Proposed text replacement:<=
/pre>
                        
 
                        
   A
                              definitive response message is composed
                              of:

                        
 

                        
   - a
                              response status and if there is no error,
                              the following:

                        
   -
                              the version of the response syntax,

                        
   - an
                              identifier of the OCSP server,

                        
   -
                              the time at which the response was
                              produced,

                        
   -
                              single responses for each of the target
                              certificates,

                        
   -
                              optional extensions,
                        
   -
                              the signature algorithm OID,

                        
   -
                              the signature computed across hash of the
                              response, and

                        
   -
                              optional certificates.<=
/p>
                        
 
                        
 
                      

                  

                

              
              


              

              
This is an
                overview section. We ought not try to duplicate the
                level of detail provided in the detailed protocol
                section.

              
A
                "definitive response" according to tho 2.1 is a response
                to an error-free request, so your first remark is
                redundant.

              


              

              
I have
                added a note about time to the current list, and changed
                "name" to identifier in bullet 2. 

              
(will be
                included in draft 11)

              


              

              
                

                  

                    

                        
7.
                            The text states on page 7:
                        
 
                        
   The
                              response for each of the certificates in a
                              request consists of
=

                        
 

                        
   - =
 target

                              certificate identifier<=
/p>
                        
   - =
 certificate

                              status value

                        
   - =
 response

                              validity interval

                        
   - =
 optional

                              extensions

                        
 
                        
However,


                            there are no explanations for the purpose of
                            these parameters and how they should be
                            processed.

                        
There

                            are also no explanations on how to process a
                            single response and how to verify that it is
                            its presence within the signed structure 

                            is valid or not valid. This is a major
                            deficiency of the current description of RC
                            2560 where there is no explanation on how to
                            validate 

                            a single response.

                        
 

                        
Text

                            proposal to be added after:
                        
 
                        
   The
                              purpose of the identifier of the OCSP
                              server is to allow OCSP 

                        
   clients
                              to find whether the definitive response
                              was signed by a CA 
=

                        
   or
                              by an OCSP Responder.
                        
 

                        
   The
                              identifier of the OCSP server SHOULD
                              either be the name or the <=
/b>

                        
   key
                              from a CA, or the name or the key from a
                              OCSP Responder.

                        
 

                        
   Unless
                              there exist local rules (which are outside
                              the scope of this 

                        
   document)

                              for verifying that a single response is
                              correctly signed, 

                        
   the
                              following applies:

                        
 

                        
   When
                              the identifier matches with the name of
                              the CA which has issued 

                        
   the
                              target certificate or corresponds to the
                              key used to issue the <=
/p>
                        
   target

                              certificate, then a single response is
                              correctly signed 

                        
   only
                              if the digital signature of the OCSP
                              response is valid using the 

                        
   key
                              used to sign the target certificate.

                        
 

                        
   When
                              the identifier does not match with the
                              name of the CA which has 

                        
   issued
                              the target certificate or does not
                              correspond to the key used =


                        
   to
                              issue the target certificate, then an
                              single response is correctly 

                        
   signed
                              only if :

                        
 

                        
       =
  (a)

                              there exists in the response an OCSP
                              certificate issued by <=
/p>
                        
       =
      the

                              CA which has issued the target certificate
                              which is 

                        
       =
      signed

                              by the same key as the one used to issue
                              the 

                        
       =
      target


                              certificate, and

                        
 

                        
       =
  (b)

                              the digital signature of the OCSP response
                              is valid using 

                        
       =
      the


                              subjectPublicKey contained in this OCSP
                              certificate.

                        
 
                        
 
                      

                  

                

              
              


              

              
Not
                broken.

              
All of
                this is already covered by the document.

              


              

              
                

                  

                    

                        
8.
                            The text states on page 7:
                        
 
                        
   T=
he
                            "revoked" state indicates that the
                            certificate has been revoked<=
/p>
                        
   (either

                              permanently or temporarily (on hold)). This

                            state MAY also be

                        
   r=
eturned
                            if the responder knows that the requested
                            certificate has

                        
   <=
b style=3D"mso-bidi-font-weight:normal">never
                              been issued during the history of the
                              associated CA using any=


                        
   c=
urrent
                            or previous issuing key. 

                        
 
                        
The

                            text is ambiguous because there are two
                            embedded parenthesis and it is unclear
                            whether the inner parenthesis means “i.e&=
#8221; or
                            “e.g”. 

                            This single sentence may let think that on
                            hold is the single case for temporarily
                            revocation. Since neither X.509 nor RFC 5280
                            address 

                            the case of a temporary revocation in the
                            context of an OCSP response (but only in the
                            context of CRLs), we are able to add another
                            case 

                            of temporary revocation which will only
                            apply in the context of OCSP.=


                        
 
                        
The

                            above sentence using the terms “<=
/span>never been issued during the
                              history of the associated CA “does

                            not capture the fact 

                            that it could be issued in the future, hence
                            why using “not yet been
                              used” would

                            be more appropriate.

                        
 
                        
Finally,

                            it would have been more logical to use
                            “unknown”. So it is important to ad=
d a note
                            to explain why we have chosen that case for
                            “legacy clients”, 

                            otherwise the people who have not
                            participate to the exchanges will not
                            understand.

                        
 

                        
Proposed text replacement:<=
/pre>
                        
 
                        
   The "revoked" state indicates that the certificate has be=
en revoked,

                        
   eith=
er permanently or temporarily.

                        
 

                        
   A certificate may be=
 temporarily revoked either because it is 

                        
   placed on hold =
(i.e. the revocation reason is certif=
icateHold) or 

                        
   because the res=
ponder is able to know, using a positive list of 

                        
   issued certific=
ates, that the serial number from the requested 

                        
   certificate has=
 not yet been used by the CA to i=
ssue a certificate 

                        
   (i.e. the revocation reason is notIssuedOrIrregularl=
yIssued).

                        
 

                        
NOTE: The "revoked" state is used rather than the ̶=
0;unknown” state, to

                        
    =
  make sure that relying parties that were conformant to RFC 256=
0

                        
    =
  will not use CRLs as a fall back mechanism. =


                        
 

                      

                  

                

              
              


              

              
I removed
                the double parenthesis and adopted your clarification
                with regard to "on hold". 

              


              

              
The text
                in draft 10 has changed from what you have commented on.
                I believe that text is better.

              


              

              
You "Note"
                has problems.

              
    
                
  1. We do not prevent responders to respond "unknown" if
                  their assessment is that this is an appropriate
                  response, considering what they know about the
                  requested serial number. Thus the term "is used" is
                  misleading.
    2. 
                
  2. This mechanisms does not "make sure" that the
                  clients do anything. It's up to the discretion of the
                  relying party to decide what source of revocation
                  checking they rely on. This does however reduce the
                  risk of clients falling back to CRL:s
    3. 
                
  3. This mechanism is not just relevant to old clients,
                  but also to new one for the same reason.
    4. 
              

              


              

              
I have
                adopted a modified version of your Note:

              


              

              

                
   NOTE: The "revok=
ed"
                    state for known non-issued certificate serial
                
        &=
nbsp;numbers is
                    allowed in order to reduce the risk of relying
                
        &=
nbsp;parties using
                    CRLs as a fall back mechanism, which would be
                
        &=
nbsp;considerably
                    higher if an "unknown" response was returned.
              

              


              

              


              

              


              

              
                

                  

                    

                        
 
                        
9.
                            The text states on page 8:
                        
 
                        
   When
                              a responder responds revoked to a status
                              request for a non-

                        
   issued

                              certificate, the responder MUST also;

                        
 

                        
    -
                              include the extended revoked definition
                              response extension

                        
      (section

                              4.8), indicating that the OCSP responder
                              supports the

                        
      extended

                              definition of revoked state to also cover
                              non-issued

                        
      certificates,

                        
 

                        
    -
                              provide the revocation reason
                              certificateHold (6), and;

                        
 

                        
    -
                              specify the revocation date January 1,
                              1970. 

                        
 
                        
As

                            already explained on the PKIX list, using
                            the revocation reason certificateHold
                            is not appropriate 

                            because it changes the meaning of
                            certificateHold. 

                        
 

                        
The

                            extended revoked definition response
                            extension is a means to signal that it not a
                            true certificate hold but a “not issued
                            certificate”. 

                            Legacy applications cannot take advantage of
                            it. 

                        
 

                        
Some

                            applications which handle non repudiation
                            enter a waiting state when the revocation
                            reason certificateHold is used thus 

                            it is not appropriate to overload the
                            meaning.

                        
 

                        
It
                            is possible to use another enumeration for
                            signalling that specific case:

                        
notIssuedOrIrregularlyIssued


                            (7).

                        
 

                        
Thus

                            for new applications it would be much better
                            to use notIssuedOrIrregularlyIssued (7) as
                            already proposed on the PKIX list.

                        
 
                        
The above sentence uses the text: <=
/span>

                        
 

                        
“a status request for a no=
n-issued certificate” 

                        
 

                        
whereas it would be more appropriate to state=
:=
 

                        
 

                        
“a status request for a se=
rial number which has not been used by the CA or used irregularly to issue a=
 certificate”.

                        
 

                        
Placing the ASN.1 description at such a place=
 in the document is inappropriate since the ASN.1 structures have not yet be=
en described. 
Thus only the functional aspects should be mentioned, but not the ASN.1 imp=
lications.

                        
 

                        
BTW, the description should follow the same o=
rder as the ASN.1. This is not the case. 

                        
 

                        
This text should be deleted from this section=
 and the appropriate text should be added when the parameters of the respons=
e are described. 

                        
 

                        
The text proposed in the previous comment sho=
uld be sufficient at this time of reading.

                        
 

                        
In addition, section 4.4.8  Extended


                              Revoked Definition should be
                            deleted.

                        
 

                        
 

                      

                  

                

              
              


              

              
The referred text has been updates in draft 09.

              


              

              
This has been discussed on the list and you have yet
                to convince the list of your new reason code.

              
I disagree as the risk of running into problems with
                the deployed base of application is hugely larger with
                introduction of a new reason code, rather than using
                certificateHold.

              
No application should be broken, since no application
                have business asking for non-issued cert serial numbers
                in the first place. Secondly, no application can assume
                that a certificateHold reason will be cleared any time
                soon.

              


              

              


              

              
                

                  

                    

                        
10.
                            The text states on page 8:
                        
 
                        
2.4  Semantics
                              of thisUpdate, nextUpdate and producedAt=


                        
 
                        
This

                            section is misplaced. At this time of
                            reading, the reader does not know that
                            thisUpdate, nextUpdate and producedAt are
                            values 

                            used by the ASN.1 structures. It is
                            appropriate to describe what theses
                            parameters mean when the ASN.1 syntax is
                            described. 

                            The current ASN.1 syntax is very badly
                            described. One would expect that after every
                            ASN.1 structure description every parameter
                            is described. 

                            Unfortunately this is not the case. 

                            

                        
The

                            text from this section is not aligned with
                            the text that is present in section 4.2.2.1. 

                        
 
                        
In

                            particular, in section 2.4:
                        
 

                        
   If
                              nextUpdate is not set, the responder is
                              indicating that newer
                        
   revocation

                              information is available all the time.

                        
 
                        
While

                            in section 4.2.2.1:

                        
 
                        
   Responses

                              where the nextUpdate value is not set are
                              equivalent 

                        
   to a
                              CRL with no time for nextUpdate (see
                              Section 2.4).

                        
 
                        
It
                            is not appropriate to have two different
                            descriptions in two different places.

                        
 

                        
Delete

                            section 2.4. See comment number 19 for the
                            description of these parameters.

                      

                  

                

              
              


              

              
Not broken.

              
The current text segments fits well into a protocol
                overview section.

              


              

              
                

                  

                    

                        
 
                        
 
                        
11.
                            Section 2.5 is also misplaced. They use
                            values from the ASN.1 syntax which has not
                            yet been described. 

                            They should be moved or incorporated in the
                            document once the ASN.1 description has been
                            done.

                        
 

                      

                  

                

              
              


              

              
Not broken.

              


              

              
                

                  

                    

                        
 

                        
12.
                            Remainder: Section 2.6 should be deleted
                            (see comment number 5).

                        
 
                      

                  

                

              
              


              

              
Not broken.

              


              

              
                

                  

                    

                        
 
                        
13.
                            Section 2.7 states:

                        
 
                        
2.7  CA
                              Key Compromise

                        
 

                        
   If
                              an OCSP responder knows that a particular
                              CA's private key has
                        
   been
                              compromised, it MAY return the revoked
                              state for all

                        
   certificates

                              issued by that CA.

                        
 
                        
This

                            section is misleading and should be removed.
                            The reason is the following:<=
/p>
                        
 

                        
The

                            relying party must verify that the
                            singleResponse is signed by a responder
                            which is entitled to do so.
                        
 

                        
a)
                            If the CA key has been compromised and if
                            the response is signed by that CA key then
                            the singleResponse will be discarded 

                            when performing the certification path
                            validation whatever the content of the
                              response may be.

                        
 

                        
b)
                            If the CA key which has issued the OCSP
                            certificate has been compromised and if the
                            response is signed by the key present 

                            in the OCSP certificate then the
                            singleResponse will be discarded when
                            performing the certification path validation
                            whatever the content of the response may
                              be.

                        
 
                        
 
                        
Security


                            must be provided using the validation of the
                            certification path. Thus it does not matter
                            what the OCSP responder states.

                      

                  

                

              
              


              

              


              

              
Not broken.

              
An OCSP responder does not have to be chained to the
                broken CA. The relying party may have other trust
                configuration at choice.

              


              

              


              

              
                

                  

                    

                        


                        

                        
 

                        
14.
                            The text states on page 11:
                        
 
                        
3.2  Signed

                              Response Acceptance Requirements

                        
 

                        
   Prior
                              to accepting a signed response as valid,
                              OCSP clients SHALL

                        
   confirm

                              that:

                        
 

                        
   1.
                              The certificate identified in a received
                              response corresponds to=


                        
      that

                              which was identified in the corresponding
                              request;

                        
 

                        
   2.
                              The signature on the response is valid;<=
/o:p>

                        
 

                        
   3.
                              The identity of the signer matches the
                              intended recipient of the

                        
      request.<=
/span>

                        
 

                        
   4.
                              The signer is currently authorized to sign
                              the response.

                        
 

                        
   5.
                              The time at which the status being
                              indicated is known to be

                        
      correct

                              (thisUpdate) is sufficiently recent.

                        
 

                        
   6.
                              When available, the time at or before
                              which newer information will

                        
      be

                              available about the status of the
                              certificate (nextUpdate) is=


                        
      greater

                              than the current time.<=
/p>
                        
 
                        
This

                            section is misplaced since it uses terms
                            from the ASN.1 syntax and the protocol
                            description has not yet been made, 

                            since it is the next section 4. Its text is
                            not correct either. 

                        
 

                        
This

                            description does not take into account the
                            fact that a BasicOCSPResponse
                            may

                            contain one or several SingleResponses.
                            

                            In particular, the sentence “The signer
                              is currently authorized to sign the
                              response&#=
8221;
                          is misleading because a signer
                            

                            may be authorized to include some Si=
ngleResponses
                            but
                            not necessarily all of them. <=
/p>
                        
 
                        
The

                            appropriate explanations should be done
                            after the description of the response, when
                            describing the processing of the response.=


                        
 

                        
Delete

                            that section.

                        
 
                      

                  

                

              
              


              

              
Not broken.

              


              

              
                

                  

                    

                        
 

                        
15.
                            On page 12, after the ASN.1 description, the
                            only parameters which are described are: <=
/o:p>

                        
hashAlgorithm=
,
                            issuerNa=
meHash,


                              issuerKeyHash and serialNumber.

                        
 

                        
This is insufficient.  In
                            order to cover the full list of parameters,
                            the following text is proposed:

                        
 
                        
   requestorName

                              is optional and MAY be used by the server
                              for access 

                        
   control
                              and audit purposes.
=

                        
 

                        
   requestList

                              contains one or more single requests.

                        
 

                        
   requestExtensions

                              is OPTIONAL.&n=
bsp;
                              Any specific extension is OPTIONAL.

                        
   The
                              critical flag SHOULD NOT be set for any of
                              them. Section 4.4 

                        
   <=
b style=3D"mso-bidi-font-weight:normal">suggests

                              several useful extensions.  Additional

                              extensions MAY be 

                        
   defined
                              in additional RFCs.
=

                        
 

                        
   reqCert

                              contains the identifier of a target
                              certificate.

                        
 

                        
   issuerNameHash

                              is the hash of the Issuer's distinguished
                              name.  The
                              

                        
   hash
                              shall be calculated over the DER encoding
                              of the issuer's name 
                        
   field
                              in the certificate being checked. =


                        
 

                        
   issuerKeyHash

                              is the hash of the Issuer's public key.  The
                              hash 

                        
   shall
                              be calculated over the value (excluding
                              tag and length) of the =


                        
   subject

                              public key field in the issuer's
                              certificate.&n=
bsp;
                              The hash 

                        
   algorithm

                              used for both these hashes, is identified
                              in 

                        
   hashAlgorithm.

                              

                        
 

                        
    &=
nbsp; The
                              primary reason to use the hash of the CA's
                              public key in 

                        
      addition

                              to the hash of the CA's name, to identify
                              the issuer, 

                        
      is
                              that it is possible that two CAs may
                              choose to use the same =


                        
      name

                              (uniqueness in the Name is a
                              recommendation that cannot be 

                        
      enforced).


                              Two CAs will never, however, have the same
                              public key 

                        
      unless

                              the CAs either explicitly decided to share
                              their private 

                        
      key,
                              or the key of one of the CAs was
                              compromised.

                        
 

                        
   serialNumber

                              is the serial number of the certificate
                              for which 

                        
   status
                              is being requested.
=

                        
 

                        
   singleRequestExtension=
s


                              is OPTIONAL.&n=
bsp;
                              Any specific extension is <=
/span>

                        
   OPTIONAL.  The
                              critical flag SHOULD NOT be set for any of
                              them. 

                        
 

                        
   The
                              requestor MAY choose to sign the OCSP
                              request. =
 In
                              that case, the

                        
   signature
                              is computed over the tbsRequest structure.  If
                              the request

                        
   is
                              signed, the requestor SHALL specify its
                              name in the requestorName

                        
   field.  Also,
                              for signed requests, the requestor MAY
                              include

                        
   certificates

                              that help the OCSP responder verify the
                              requestor's

                        
   signature
                              in the certs field of Signature.

                        
 
                      

                  

                

              
              


              

              
Not broken.

              
The current text is short, but it is actually
                sufficient from the context of the ASN.1 definitions of
                the section. This is a detailed protocol section and the
                reader need to understand ASN.1 in any case to
                understand and implement the section.

              
The information about criticality is already covered
                in the extension section.

              


              

              


              

              
                

                  

                    

                        
 
                        
16. Section 4.1.2 is called: “Notes
                              on the Request Syntax”

                        
 
                        
The

                            first paragraph has been moved after the
                            description of issuerKeyHash
                            and

                            thus is no more needed.

                        
 
                        
The

                            second paragraph has been moved after the
                            description of requestExtensions.
                            

                            However, the sentence 

                            “ Unrecognized
                              extensions MUST be ignored (unless they
                              have the critical flag set and are not
                              understood)”
                            

                            has been deleted since it applies to the
                            OCSP responder and not to the OCSP client.
                            Thus it is no more needed.
                        
 
                        
The

                            third paragraph applies to signed requests.
                            However, it should belong to a section
                            dedicated on how clients should build OCPS
                            requests, 

                            which is currently missing. See the next
                            comment.

                        
 

                        
This

                            section should be deleted.
                        
 

                      

                  

                

              
              


              

              
Not broken.

              


              

              
                

                  

                    

                        
 

                        
17.
                            There should be a new section called: “Requirements for OCSP
                              clients”. 

                        
 
                        
It
                            is important first to re-advertise that the
                            request may be about several certificates. 
=

                            Thus it is important to describe the process
                            for building a request, which is currently
                            missing.

                        
 
                        
   An
                              OCSP request allows getting in the same
                              response the revocation 

                        
   status
                              of one or more certificates.  In
                              order to request the 
                        
   status
                              of one or more certificates in a single
                              request, OCSP 

                        
   clients

                              SHALL follow the following rules :=


                        
 

                        
   For
                              each candidate certificate, OCSP clients
                              SHALL verify 

                        
   whether

                              there exists a locally defined rule for
                              the certificate in 
=

                        
   question

                              which indicates the URI where the OCSP
                              responder is 

                        
   located.  If
                              this rule exists, it SHALL be followed. =


                        
 

                        
   Otherwise,

                              OCSP clients SHALL determine whether the
                              candidate 

                        
   certificate

                              contains an AIA extension with an
                              accessMethod which 
=

                        
   contains
                              the id-ad-ocsp OID.  If it
                              is the case, the accessLocation 

                        
   contains
                              a uniformResourceIdentifier (URI) which
                              indicates the 

                        
   location
                              of the OCSP server for that certificate. 

                        
 

                        
   Certificates

                              that contain the same URI MAY be grouped
                              in a single 

                        
   request.

                        
 

                        
Note:  For
                              each candidate certificate, when
                              performing the path 
                        
       validation


                              algorithm, the OCSP client SHOULD verify
                              that the 

                        
       current

                              time is within the validity period of the
                              target 

                        
       certificate.  Certificates

                              which are outside their validity <=
/span>

                        
       period

                              SHOULD NOT be included in the request.

                        
 
                        
   The
                              requestor MAY choose to sign the OCSP
                              request. In that case, the<=
/b>

                        
   signature
                              is computed over the tbsRequest structure.
                              If the request

                        
   is
                              signed, the requestor SHALL specify its
                              name in the requestorName

                        
   field.
                              Also, for signed requests, the requestor
                              MAY include

                        
   certificates

                              that help the OCSP responder verify the
                              requestor's

                        
   signature
                              in the certs field of Signature.

                        
 
                      

                  

                

              
              


              

              
Not broken.

              


              

              
Your text may provide guidance that could be useful
                to some implementers, but is completely beyond this
                document and further, not generally applicable or true.
              
As an example, an organisation may setup an in house
                locally configured OCSP responder that responds to all
                certificates "out there" that is relevant to that
                organisation.

              
Such clients would just blindly send OCSP requests to
                their local responder, disregarding any information in
                the cert.

              
It's totally beyond this spec to have an opinion
                about this.

              


              

              


              

              
                

                  

                    

                        
 
                        
18.
                            The text states on page 14:
                        
 
                        
   The
                              responder MAY include certificates in the

                        
   certs
                              field of BasicOCSPResponse that help the
                              OCSP client verify the<=
/p>
                        
   responder's

                              signature. If no certificates are included
                              then certs

                        
   SHOULD
                              be absent.

                        
 
                        
While

                            this sentence is true, it is not sufficient.
                            In order to allow verifying every SingleResponse,
                            

                            it is important to include the relevant
                            certificates which are pertinent to every SingleResponse.

                        
 

                        
Proposed


                            full text replacement:

                        
 
                        
   T=
he
                            responder MAY include certificates in the
                            certs field of 

                        
   B=
asicOCSPResponse


                            that help the OCSP client verify the
                            responder's 

                        
   s=
ignature.

                        
 
                        
   For
                              every SingleResponse where the responder
                              is not a CA, the 

                        
   responder

                              SHALL include the relevant OCSP
                              certificate in the certs 

                        
   field
                              of BasicOCSPResponse in order to allow the
                              OCSP client 

                        
   verifying

                              the responder was entitled to include that
                              SingleResponse 

                        
   in
                              the signed BasicOCSPResponse.

                        
 

                        
   If no certificates are included
                            then certs SHOULD be absent.
                        
 

                      

                  

                

              
              


              

              
Not broken.

              


              

              
This requirement would break backwards compatibility
                with RFC 2560.

              
Further this would not be needed for a locally
                configured responder.

              


              

              
                

                  

                    

                        
 

                        
19.
                            Page 15. The ASN.1 syntax should be changed
                            in order to be able to use the enumeration
                            case 7 that is not used for CRLs. 

                            This leads to the following change:<=
/span>

                        
 

                        
Current

                            text:

                        
 

                        
       revocationReas=
on    [0]     EXPLICIT

                              CRLReason OPTIONAL }
                        
 

                        
Proposed


                            text change:

                        
 

                        
Current

                            text:

                        
 

                        
       revocationReas=
on

                                &n=
bsp;[0]     EXPLICIT

                              RevocationReason OPTIONAL }=


                        
 

                        
RevocationReason
                              ::=3D ENUMERATED {
                        
       =
 unspecified    &n=
bsp;      &nb=
sp;      =
;  (0),

                        
       =
 keyCompromise    =
       &=
nbsp;     &nb=
sp;(1),

                        
       =
 cACompromise    &=
nbsp;      &n=
bsp;     &nbs=
p; (2),

                        
       =
 affiliationChanged    =
      &n=
bsp;  (3),=


                        
       =
 superseded    &nb=
sp;                (4),

                        
       =
 cessationOfOperation           (5),

                        
       =
 certificateHold   &nbs=
p;       =
;     =
(6),

                        
       =
 notIssuedOrIrregularlyIssued


                                (7),

                        
       =
 removeFromCRL    =
       &=
nbsp;     &nb=
sp;(8),

                        
       =
 privilegeWithdrawn          &n=
bsp;  (9),

                        
       =
 aACompromise    &=
nbsp;      &n=
bsp;     &nbs=
p;(10) }

                        
 

                      

                  

                

              
              


              

              
Not broken.

              


              

              
You have to convince the list about your new reason
                code.

              


              

              
                

                  

                    

                        
 

                        
20. Page 15. After the ASN.1
                            syntax, there is no description of every
                            parameter, neither on its use 

                            (except a few words in section
                            4.2.2.1=

                              Time about
                            thisUpd=
ate,

                              nextUpdate and producedAt).

                        
 

                        
Every parameter needs to b=
e
                            described and explained.

                        
 

                        
   responderID

                              indicates either the name or the key from
                              a CA, or the 

                        
   name
                              or the key from a OCSP Responder.<=
/span>

                        
 

                        
   producedAt

                              indicates the time at which this response
                              was signed.

                        
 

                        
   responses

                              contains one or more single responses.

                        
 

                        
   responseExtensions

                              is OPTIONAL.&n=
bsp;
                              Any specific extension is OPTIONAL.

                        
   The
                              critical flag may or may not be set.

                        
 

                        
   certID
                              is usually a copy of the same field which
                              was placed in the 

                        
   request,
                              but for OCSP responders which pre-produce
                              signed responses 

                        
   certID
                              may be the identifier of a target
                              certificate that was not 

                        
   present
                              in the request (see the end of section
                              4.2).

                        
 

                        
   certStatus

                              indicates the status of the certificate:
                              either good, 

                        
   revoked
                              or unknown.

                        
 

                        
   thisUpdate

                              indicates the time at which the status
                              being indicated 

                        
   is
                              known to be correct.
                        
 

                        
   nextUpdate

                              indicates the time at or before which
                              newer information 

                        
   will
                              be available about the status of the
                              certificate.&n=
bsp;
                              If 

                        
   nextUpdate

                              is not set, the server is indicating that
                              newer 

                        
   revocation

                              information is available all the time. <=
/o:p>

                        
 

                        
   If
                              nextUpdate is set, it often corresponds to
                              the {thisUpdate, 

                        
   nextUpdate}

                              interval in CRLs.  Responses
                              whose nextUpdate value is <=
/b>

                        
   earlier
                              than the local UTC time value SHOULD be
                              considered 

                        
   unreliable.  Responses

                              whose thisUpdate time is later than the
                              local 

                        
   UTC
                              time SHOULD be considered unreliable.

                        
 

                        
   singleExtensions

                              is OPTIONAL.&n=
bsp;
                              Any specific extension is OPTIONAL.

                        
   The
                              critical flag SHOULD NOT be set for any of
                              them.

                        
 

                        
   revocationTime


                              indicates the time at which the
                              certificate was 

                        
   revoked.

                        
 

                        
   revocationReason

                              is OPTIONAL. &=
nbsp;It
                              includes all the cases that are 

                        
   present
                              in CRLReason used for CRLs and an
                              additional case 7 which is<=
/b>

                        
   not
                              used for CRLs.=
  Case
                              7 is called notIssuedOrIrregularlyIssued.
                              

                        
 

                        
      -
                              "notIssued" corresponds to the case where
                              the certificate 

                        
       =
  serial

                              number that was sent was erroneous and has
                              not yet 

                        
       =
  been

                              used by the CA at the time of the query,=


                        
 

                        
      -
                              "irregularlyIssued" corresponds to the
                              case where the 

                        
       =
  certificate


                              serial number that was sent really exists
                              in a 

                        
       =
  certificate

                              that is correctly signed, but to its
                              knowledge 

                        
       =
  the
                              CA has not issued a certificate with such
                              a serial 

                        
       =
  number.

                               A=
s
                              an example, it may have been issued by the
                              CA 

                        
       =
  because

                              the RA was compromised. 

                        
 

                        
   When=
 a responder responds revoked to a status request for which it 

                        
   knows that the serial number has not been used by the CA or has =


                        
   been irregularly used irregularly to issue a certificate, then <=
/span>

                        
   in RevokedInfo the responder MUST:

                        
 

                        
      - specify the revocationTime :=
  January 1, 1970,

                        
     =
; - provide the revocation=
Reason: notIssuedOrIrregularlyIssued (7).

                        
 

                        
   and in SingleResponse the responder MUST =
NOT include the nextUpdate.

                        
 

                        
   The
                              response MUST include a SingleResponse for
                              each certificate in
=

                        
   the
                              request and SHOULD NOT include any
                              additional SingleResponse

                        
   elements.  However,

                              there is one exception: 

                        
 

                        
      OCSP=


                              responders MAY pre-produce signed
                              responses specifying the 

                        
      stat=
us
                              of certificates at a specified time.  The
                              time at which 

                        
      the

                              status was known to be correct SHALL be
                              reflected in the 

                        
      this=
Update

                              field of the response. =


                        
 

                        
      OCSP=


                              responders that pre-generate status
                              responses MAY return 
                        
      resp=
onses

                              that include additional SingleResponse
                              elements if

                        
      nece=
ssary

                              to improve response pre-generation
                              performance or cache
                        
      effi=
ciency

                              (as permitted in [RFC5019]).

                        
 

                        
Since the text above provi=
des
                            all the explanations at the level of the
                            ASN.1 parameters, the general text 

                            from section 4.2.2.3 Basic=
 Response is no more need and should be
                            deleted.

                        
 

                      

                  

                

              
              


              

              
Preliminary I would say "not broken".

              
If you don't replace 4.2.2.3, then what really are
                you missing?

              


              

              
                

                  

                    

                        
 
                        
21.
                            0n page 16, there is a section 4.2.2.2 called &=
#8220;Authorized
                              Responders”

                        
 

                        
Section

                            4.2.2.2 states:

                        
 
                        
   (…)

                        
   This
                              certificate MUST be issued directly by the
                              CA that issued the

                        
   certificate

                              in question.

                        
 

                        
   The
                              CA SHOULD use the same issuing key to
                              issue a delegation

                        
   certificate

                              as was used to sign the certificate being
                              checked for

                        
   revocation.

                              Systems relying on OCSP responses MUST
                              recognize a

                        
   delegation

                              certificate as being issued by the CA that
                              issued the

                        
   certificate

                              in question only if the delegation
                              certificate and the
=

                        
   certificate

                              being checked for revocation was signed by
                              the same key.

                        
 
                        
This

                            section would need to reformatted to address
                            CA requirements first and then OCSP
                            responder requirements:

                        
 
                        
   (…)

                        
   This
                              certificate MUST be issued directly by the
                              CA that issued the

                        
   certificate

                              in question.&n=
bsp;
                              The CA SHOULD use the same issuing
                              key to 

                        
   issue
                              a delegation certificate as was used to
                              sign the certificate 
                        
   being

                              checked for revocation. 

                        
 

                        
   Systems

                              relying on OCSP responses MUST be able
                                to recognize a 
                        
   delegation

                              certificate as being issued by the CA that
                              issued the 

                        
   certificate

                              in question if the delegation certificate
                              and 

                        
   the
                              certificate being checked were
                              signed by the same key.=


                        
 
                      

                  

                

              
              


              

              
I disagree. The CA is actually free to do anything,
                but cannot expect the client to recognise the responder
                as authorised unless the same private key is used.

              
The current text places the requirement where they
                belong.

              


              

              
                

                  

                    

                        
 
                        
22.
                            On page 17, the text states:<=
/p>
                        
 
                        
   They
                              MUST reject the

                        
   response
                              if the certificate required to validate
                              the signature on the
                        
   response

                              fails to meet at least one of the
                              following criteria:
=

                        
 
                        
This is ambiguous. It is
                            inappropriate to have a negative statement
                            like “They
                              MUST reject”. 

                            The sentence should be turned in the
                            positive form “They SHALL acc=
ept”
                            

                        
 
                        
Since

                            the ASN.1 syntax has now be described, it is
                            possible to be more specific.=


                        
 

                        
The

                            first occurrence of the word “response=
221;
                            should be changed into “singleResponse=
221;,
                            while the second occurrence 

                            of the word “response” should be ch=
anged
                            into “ResponseData”

                        
 
                        
Proposed


                            text replacement:

                        
 
                        
   They
                              SHALL accept a singleResponse if the
                              certificate required to 

                        
   validate
                              the signature placed on the ResponseData
                              meets one of the 

                        
   following

                              criteria:

                      

                  

                

              
              


              

              


              

              
No, this change is not backwards compatible.

              
So state the requirements for rejection is not
                equivalent to stating requirements for acceptance.

              
There may be other locally configured reasons to
                reject in addition to those listed in the standard.

              


              

              


              

              
                

                  

                    

                        
 
                        
 
                        
23.
                            On page 17, the text states:<=
/p>
                        
 
                        
   3.
                              Includes a value of id-kp-OCSPSigning in
                              an ExtendedKeyUsage
=

                        
   extension

                              and is issued by the CA that issued the
                              certificate in

                        
   question
                              as stated above."

                        
 
                        
In

                            order to be crystal clear, it is proposed to
                            change the wording in the following way:

                        
 
                        
   3.
                              Includes a value of id-kp-OCSPSigning in
                              an ExtendedKeyUsage
=

                        
   extension

                              and was signed by the CA using the same
                              key that used 

                        
   to
                              issue the certificate in question.=


                        
 
                      

                  

                

              
              


              

              
No, issuing with another key is not prohibited, and
                may be accepted by some clients as an authorised
                responder.

              


              

              
                

                  

                    

                        
 
                        
24.
                            On page 17, the text states:<=
/p>
                        
 
                        
   This
                              SHOULD be a non-critical extension. The
                              value of the extension =


                        
   SHALL
                              be NULL.

                        
 

                        
The ASN.1 syntax is missin=
g.
                            Add: 

                        
 

                        
   NoCheck
                              ::=3D NULL

                        
 

                        
 
                      

                  

                

              
              


              

              
Moving this to a separate discussion.

              
I'm not sure what the preferred way to describe this
                is.

              


              

              


              

              
                

                  

                    

                        
25.
                            Remainder: On page 18, the general text from
                            section <=
/span>4.2.2.3
                              Basic Response is no more needed a=
nd 

                            should be deleted. See comment 20.

                        
 

                        
 
                      

                  

                

              
              


              

              
Not broken.

              


              

              
                

                  

                    

                        
26.
                            On page 24, text should be added to the
                            Security consideration section:

                        
 
                        
Different results when using
                              OCSP and CRLs

                        
 

                        
   OCSP
                              clients or verifiers must build and verify
                              a certification path 
                        
   for
                              each target certificate up to a trusted
                              root.  When
                              an OCSP 

                        
   Responder
                              is using published CRLs, it must also
                              build and verify a 
=

                        
   certification

                              path for the CRLs it uses up to a trusted
                              root.

                        
 

                        
   However,
                              it should be realized that the root used
                              by an OCSP 

                        
   Responder
                              to verified these CRLs is not necessarily
                              the same as the 

                        
   one
                              that would be used by the OCSP client, if
                              it were going to verify 

                        
   the
                              CRLs itself.&n=
bsp;
                              Hence the revocation status may not
                              be identical 

                        
   in
                              both cases.

                        
 

                        
 

                      

                  

                

              
              


              

              
I don't understand this one.

              


              

              
                

                  

                    

                        
27.
                            On page 24, text should be added to the
                            Security consideration section:

                        
 

                        
Denial of service attack
                              using a flood of queries

                        
 

                        
   A
                              denial of service vulnerability is evident
                              with respect to a flood 

                        
   of
                              queries. =
 The

                              production of a cryptographic signature =


                        
   significantly

                              affects response generation cycle time,
                              thereby 

                        
   exacerbating

                              the situation. 

                        
 

                        
   The
                              flood of queries may either come from a
                              flood attack or from the 

                        
   fact
                              that there are too many certificates
                              supported by the same OCSP =


                        
   responder.  In
                              the later case, the number of queries can
                              be 

                        
   reduced
                              by using a technique similar to the
                              splitting of CRLs: 
=

                        
 

                        
      When=

                              a block of certificates have been issued
                              with the same 

                        
      acce=
ssLocation

                              in the AIA extension field of these
                              certificates, 

                        
      then=

                              the accessLocation should be changed.  In
                              this way, a given 

                        
      OCSP=


                              server will only be responsible for a
                              block of certificates.<=
/p>
                        
 

                      

                  

                

              
              


              

              
If the security considerations section is talking
                about splitting OCSP responders in this way, then the
                document itself need to introduce the subject.

              
I would suggest that it is beyond this update to do
                so.

              


              

              
                

                  

                    

                        
 

                        
28.
                            On page 31, the text states.<=
/p>
                        
 
                        
   An
                              alternative to this module that conforms
                              to the 2002 version of =


                        
   ASN.1
                              may be found in Section 4 of [RFC5912]. =


                        
=
 

                        
RFC

                            5912 omits to define the nocheck extension.
                            Thus it is inappropriate to refer to RFC
                            5912. 

                        
 

                        
The

                            corrected module should be defined in this
                            new draft. 

                            A corrected module is provided in draft-pinkas-rfc2560bis-03.

                        
 
                      

                  

                

              
              


              

              
Will move this (as stated above) to a separate
                discussion.

              


              

              
                

                  

                    

                        
 
                        
29.
                            Different topics are not covered by the
                            document. These topics are important. 

                            The following comments propose text to be
                            placed in annexes. Three annexes are being
                            proposed.

                        
 

                        
Note:

                            The texts are extracted from <=
b style=3D"mso-bidi-font-weight:normal">draft-pinkas-rfc2560bis-03.

                        
 
                        
 
                      

                  

                

              
              


              

              
Not broken.

              
Each such amendment need to be thoroughly reviewed
                and motivated.

              


              

              


              

              
                

                  

                    

                        
30.
                            First annex being proposed. This annex is
                            important, because key rollover is not
                            addressed in the draft.

                        
 
                        
KEY ROLLOVER

                        
 

                        
1. CA that directly supports
                              an OCSP service

                        
 

                        
   When
                              a CA that directly supports an OCSP
                              service performs a key =


                        
   rollover:

                        
 

                        
   -
                              for certificates issued under the old key,
                              the CA SHALL continue <=
/p>
                        
     to
                              sign the revocation status of OCSP
                              responses with that old key 

                        
     at
                              least until all these certificates are
                              expired, and

                        
 

                        
   -
                              for certificates issued under the new key,
                              the CA SHALL change the 

                        
     accessLoca=
tion

                              in the AIA extension field of these
                              certificates 

                        
     and
                              sign the revocation status of OCSP
                              responses with that new key 

                        
     at
                              least until all these certificates are
                              expired.

                        
 

                        
   Note:
                              The change in accessLocation is necessary
                              when the CA rekeys 
=

                        
       =
  to

                              meet the following constraints imposed by
                              this standard: 

                        
 

                        
       =
     1)

                              a BasicOCSPResponse can only be signed
                              using a single 

                        
       =
       
                              private key; 
                        
 

                        
       =
     2)

                              the response must be signed using the same
                              CA key that 

                        
       =
       &=
nbsp;was
                              used to sign the certificate in question;
                              and

                        
 

                        
       =
     3)

                              the OCSP response needs to cover all the
                              certificates 

                        
       =
       
                              queried in the OCSP request.

                        
 
                        
2. CA that uses OCSP
                              responders

                        
 
                        
   When
                              a CA that uses OCSP Responders performs a
                              key rollover, then 
=

                        
   it
                              MUST either designate a new OCSP Responder
                              or keep the current 
                        
   OCSP
                              Responder(s).

                        
 

                        
   If
                              the CA designates a new OCSP Responder,
                              then it SHALL change the 

                        
   accessLocation

                              in the AIA extension field for the newly
                              issued 

                        
   certificates

                              and issue an OCSP certificate to the new
                              OCSP Responder 

                        
   using
                              its new key.

                        
 

                        
   If
                              the CA keeps the same OCSP Responder(s),
                              then it SHALL continue =


                        
   to
                              use the same accessLocation(s) in the AIA
                              extension field for the 

                        
   newly
                              issued certificates and issue an OCSP
                              certificate to the 
=

                        
   appropriate

                              OCSP Responder(s) using its new key.

                        
 

                        
   Note:
                              The CA may need to continue issuing
                              certificates to the OCSP 

                        
   Responder(s)

                              using the old CA key until all the
                              certificates issued 
                        
   under
                              the CA' old key for which the OCSP
                              Responder(s) are 

                        
   authoritative

                              have expired.

                        
 

                        
3. OCSP Responder key
                              rollover

                        
 

                        
   When
                              an OCSP Responder performs a key rollover
                              (asynchronously from 
                        
   a CA
                              key rollover), then each CA which has
                              designated an OCSP 
=

                        
   Responder

                              SHALL issue a new certificate for that
                              OCSP Responder and 
=

                        
   for
                              each of its issuing keys which meets the
                              following property: 
                        
 

                        
      -
                              the issuing key has been used to sign at
                              least one certificate <=
/p>
                        
       =
 which

                              contains an AIA extension designating that
                              OCSP Responder 

                        
       =
 and

                              that certificate is not yet expired.

                        
 

                        
   An
                              OCSP Responder key rollover does not
                              affect the values of the 

                        
   URIs
                              that are placed in the accessLocation
                              field from the target <=
/p>
                        
   certificates.  One
                              or more OCSP Responder MAY respond to an
                              OCSP 

                        
   request

                              addressed at a given URI picked from the
                              accessLocation 

                        
   field
                              from a target certificate.  Each
                              OCSP Responder MAY use a 

                        
   different

                              signing key, as long as it got an OCSP
                              certificate 

                        
   appropriate

                              for that signing key and for the target
                              certificate. 

                        
 
                        
 
                        
31.
                            Second annex being proposed. This annex is
                            important because it describes the
                            validation of an OCSP response in the past 
=

                            which is of a particular importance when
                            validating electronic signatures.

                        
 
                        
Response processing by an
                              OCSP client

                        
 

                        
   OCSP
                              responses can be verified at the current
                              time by an OCSP client =


                        
   when
                              receiving a response, whereas old
                              responses can be verified at 

                        
   a
                              time in the past by a verifier.  The
                              algorithm below addresses <=
/b>

                        
   both
                              cases.

                        
 

                        
   Prior
                              to processing a basic response, OCSP
                              clients MUST determine =


                        
   the
                              checking time, which may be either the
                              current time or a time =


                        
   in
                              the past.

                        
 

                        
   OCSP
                              clients or verifiers SHALL check if the
                              response contains 

                        
   responseExtensions.

                              If such an extension is found and is
                              recognized, 

                        
   it
                              MUST be processed.  If
                              such a critical extension is found and <=
/o:p>

                        
   is
                              not recognized, the whole OCSP response
                              MUST be considered as <=
/p>
                        
   invalid.

                        
 

                        
   If
                              the checking time is the current time, and
                              if a nonce extension 
                        
   has
                              been used in the request and is recognized
                              (see section 4.5.1), 
                        
   OCSP
                              clients MUST check whether the same nonce
                              is present in the 

                        
   response.  If
                              the nonce is not present or is different,
                              then the 

                        
   OCSP
                              response MUST be discarded.=


                        
 

                        
   Only
                              the single response(s) which are/is of
                              interest SHALL be 

                        
   checked.

                        
 

                        
STEP 1

                        
 

                        
   OCSP
                              clients or verifiers SHALL verify that the
                              certificate 

                        
   identified

                              in a single response is of interest.  Otherwise,

                              proceed 

                        
   to
                              step 3.

                        
 

                        
   If
                              the certificate status included in a
                              single certificate response 

                        
   is
                              "unknown", then the revocation status of
                              that certificate is 
                        
   "unknown",

                              and proceed to step 3.<=
/p>
                        
 

                        
   If
                              the certificate status from the single
                              certificate response is 

                        
   either

                              "good" or "revoked", OCSP clients or
                              verifiers SHALL check <=
/p>
                        
   that
                              the checking time is within the validity
                              period of the target 
                        
   certificate.  If it
                              is not the case, then the revocation
                              status of 

                        
   that
                              certificate is "unknown" and proceed to
                              step 3.

                        
 

                        
   If
                              the checking time is the current time, and
                              if a nonce has been 
                        
   used
                              in the request, then proceed to step 2.<=
/o:p>

                        
 

                        
   If
                              the checking time is the current time, and
                              if no nonce has been 
                        
   used
                              in the request, OCSP clients MUST check
                              that the producedAt
=

                        
   field
                              is within a time window that is "close
                              enough" to the current =


                        
   time.
                              

                        
 

                        
   Note:
                              the notion of "close enough" is a local
                              matter.  =
It
                              can be set 

                        
       =
  to
                              a few minutes to allow for small UTC time
                              differences 

                        
       =
  between

                              the client and the server or to a few
                              hours in case 

                        
       =
  the

                              server is producing pre-computed
                              responses.

                        
 

                        
   If
                              the checking time is a time in the past,
                              verifiers MUST check 
                        
   that
                              the producedAt field is in accordance with
                              the verification 

                        
   rules
                              (e.g. close and/or after the date of a
                              time-stamp token).

                        
 

                        
   In
                              addition, if the nextUpdate field is
                              present, OCSP clients MUST =


                        
   check
                              that the time which is indicated is
                              greater than the checking <=
/b>

                        
   time,

                              otherwise the single response MUST be
                              discarded.

                        
 

                        
   If
                              checks are successful, then OCSP clients
                              MUST process the 

                        
   singleExtensions


                              field, if it is present. 

                        
 

                        
   If
                              the criticality flag is set and the
                              extension is not understood, 

                        
   then
                              the status of the certificate shall be
                              "unknown" and proceed to 

                        
   step
                              3.  Otherwise,

                              proceed to step 2. 
=

                        
 

                        
   If
                              the extension is understood, then the
                              extension MUST be 

                        
   processed.  According
                              to its content proceed either to step 2 or
                              to 

                        
   step
                              3. 

                        
 

                        
STEP 2

                        
 

                        
   OCSP
                              clients or verifiers MUST build and verify
                              a certification path 
                        
   for
                              that certificate up to a trusted root, so
                              that they have the 
=

                        
   knowledge
                              of the CA public key value that was used
                              to sign the 

                        
   target

                              certificate.&n=
bsp;
                              The revocation status of each
                              certificate of 

                        
   that
                              certification path (except the target
                              certificate) SHALL be <=
/p>
                        
   checked.

                        
 

                        
   If
                              no path can be built or if one of the
                              certificates of the path is 

                        
   revoked,

                              then the revocation status of that
                              certificate is "unknown", <=
/b>

                        
   and
                              proceed to step 3. 
=

                        
 

                        
   If
                              the certification path (except the target
                              certificate) is valid, =


                        
   then
                              two cases need to be considered:

                        
 

                        
   a)
                              If the responderID matches with the name
                              or the key from the CA =


                        
      whic=
h
                              has issued the target certificate, then
                              check whether the 

                        
      OCSP=


                              response is signed by the same key that
                              was used to sign 

                        
      the

                              target certificate.
=

                        
 

                        
       =
      If

                              it is the case, then the revocation status
                              of that 

                        
       =
      certificate


                              as indicated in the certStatus field is =


                        
       =
      accepted

                              and proceed to step 3.<=
/p>
                        
 

                        
       =
      If

                              it is not the case, then the revocation
                              status of that 

                        
       =
      certificate


                              is "unknown" and proceed to step 3.

                        
 

                        
   b)
                              If the responderID does not match with the
                              name or the key from 
                        
      the
                              CA which has issued the target
                              certificate, then it indicates 

                        
      the
                              name or the key from an OCSP Responder.  Check
                              whether there 

                        
      exis=
ts
                              a local rule which applies to this target
                              certificate to 

                        
      veri=
fy

                              that the signature of the
                              BasicOCSPResponse is valid for 

                        
      that=


                              single response.  If
                              this rule exists, it SHALL be followed. =


                        
 

                        
      Othe=
rwise

                              check whether there is an OCSP certificate
                              (i.e. which 

                        
      has
                              both the ocspSigning OID in the extended
                              key usage extension 
                        
      and
                              the digitalSignature bit in the key usage
                              extension) signed 

                        
      by
                              the same key that was used to sign the
                              target certificate. 
                        
      This=


                              certificate MUST be present in the certs
                              field from the 

                        
      Basi=
cOCSPResponse.


                              

                        
 

                        
       =
   If

                              such certificate is not found or is
                              invalid, then the 

                        
       =
   revocation


                              status of that certificate is "unknown"
                              and 

                        
       =
   proceed

                              to step 3.

                        
 

                        
       =
   If

                              such certificate exists and if the
                              checking time is 

                        
       =
   within

                              the validity period of this certificate,
                              then it MUST 

                        
       =
   be

                              verified whether the OCSP response can be
                              verified using 

                        
       =
   the

                              public key that is present in the OCSP
                              Certificate. 

                        
 

                        
       =
      If

                              it is not the case, then the revocation
                              status of that 

                        
       =
      certificate


                              is "unknown" and proceed to step 3.

                        
 

                        
       =
      If

                              it is the case, then it MUST be verified
                              that the OCSP 

                        
       =
      Certificate


                              has not been revoked.
                        
 

                        
     If
                              one of these conditions is met, then the
                              status for the target <=
/p>
                        
     certificat=
e

                              as indicated in the certStatus field is
                              accepted, 

                        
     otherwise

                              the revocation status is "unknown".

                        
 

                        
STEP 3

                        
 

                        
   If
                              there exists another single certificate
                              status response for a <=
/p>
                        
   target

                              certificate that is of interest, then
                              proceed to step 1. 
=

                        
   Otherwise

                              the basic response is now processed.

                        
 
                        
 
                        
32.
                            Third annex being proposed. This annex is
                            important because it provides guidance on
                            how to build an OCSP responder in the three
                            cases. 

                            Many text portions are similar, but three
                            full texts are provided in order to provide
                            a better clarity for each of the three
                            cases.

                        
 
                        
1. Request processing by OCSP
                              servers

                        
 

                        
   The
                              behavior of an OCSP server will be
                              different whether the OCSP =


                        
   server
                              is a CA acting as an OCSP responder, is an
                              OCSP Responder 

                        
   which

                              received a delegation from one or more
                              CAs, or is a locally 
                        
   trusted

                              Responder.

                        
 

                        
1.1. Processing by a CA
                              acting as an OCSP responder=


                        
 

                        
   The
                              OCSP responder SHALL maintain a list of
                              entries. Each entry 
                        
   SHALL

                              contain:

                        
 

                        
     -
                              the URI associated to the OCSP responder,
                              from which the OCSP 
                        
       requests

                              are received, 

                        
 

                        
     -
                              the DN from a CA,

                        
 

                        
     -
                              an issuing public key from a CA,

                        
 

                        
     -
                              the method(s) used to know for which
                              subset of certificates =


                        
       issued

                              by the CA it is responsible for, <=
/span>

                        
 

                        
     -
                              the method(s) used to obtain the
                              revocation status of that <=
/b>

                        
       subset

                              of certificates issued under that CA
                              issuing public key, 
                        
       and

                        
 

                        
     -
                              the method used to gain access and sign
                              with the private key 
                        
       corresponding

                              to the issuing public key.<=
/b>

                        
 

                        
   For
                              a given URI value, the OCSP responder
                              SHALL only use one CA <=
/p>
                        
   key
                              pair value. 

                        
 

                        
   When
                              it receives an OCSP request on that URI,
                              the OCSP responder 
=

                        
   SHALL
                              handle exceptions according to section
                              2.3. 

                        
 

                        
   If
                              the OCSP request contains the name of a
                              requestor, the OCSP 
                        
   responder

                              SHALL verify whether there exists a
                              locally defined rule 
                        
   which

                              regulates access control.  If
                              this rule exists, it SHALL be 

                        
   followed.

                        
 

                        
   Then,
                              for each target certificate, the OCSP
                              responder SHALL verify =


                        
   whether
                              both the hash of the issuer's DN and the
                              hash of the issuer 
=

                        
   public
                              key which are present in the request are
                              eligible to a 

                        
   locally

                              defined rule which indicates that the OCSP
                              responder is 

                        
   responsible

                              to provide the revocation status of that
                              target 

                        
   certificate.  If
                              this rule exists, it SHALL be followed.<=
/o:p>

                        
 

                        
   Otherwise,

                              the OCSP responder SHALL determine whether
                              it is 

                        
   responsible

                              to provide the revocation status of that
                              target 

                        
   certificate

                              according to the following rule.

                        
 

                        
   For
                              each target certificate, the OCSP
                              responder SHALL verify whether 

                        
   both
                              the hash of the issuer's DN and the hash
                              of the issuer public 
                        
   key
                              which are present in the request match
                              respectively with the DN 

                        
   and
                              the hash of the public key of contained in
                              an entry from the 

                        
   list
                              of entries maintained by this OCSP
                              responder. 

                        
 

                        
   When
                              there is no match, then the OCSP responder
                              SHALL indicate the 
=

                        
   "unknown"

                              status and proceed with the next target
                              certificate from 

                        
   the
                              OCSP request.

                        
 

                        
   When
                              there is a match, then the OCSP responder
                              SHALL use the serial 
                        
   number
                              of the target certificate that is present
                              in the request and 
=

                        
   determine

                              the revocation status of that certificate
                              according to 

                        
   the
                              method(s) defined in the entry. 

                        
 

                        
   When
                              the revocation status is provided by the
                              server using a real 
                        
   time
                              access to a database of revocation
                              statuses of issued 
=

                        
   certificates,

                              then the thisUpdate field SHALL be present
                              in the

                        
   SingleResponse


                              response whereas the nextUpdate field
                              SHALL be 

                        
   missing.
                              

                        
 

                        
   Otherwise,

                              both the thisUpdate and the nextUpdate
                              fields SHALL be 

                        
   present
                              in the SingleResponse. =


                        
 

                        
   The
                              time at which this response will be signed
                              MUST be indicated in 
                        
   the
                              producedAt field from the SingleResponse.

                        
 

                        
   If a
                              singleRequestExtensions is present in the
                              request it MUST be 
=

                        
   processed.<=
/span>

                        
 

                        
   If
                              there is another target certificate
                              present in the request, it =


                        
   SHALL
                              be processed in the same way.

                        
 

                        
   If a
                              requestExtensions is present in the
                              request it MUST be 
=

                        
   processed.<=
/span>

                        
 

                        
   The
                              OCSP response MUST be signed using the CA
                              issuing private key.
                        
 

                        
 

                        
1.2. Processing by an OCSP
                              Responder

                        
 

                        
   For
                              each CA from which the OCSP Responder has
                              received a delegation, =


                        
   the
                              OCSP Responder SHALL maintain a list of
                              entries. 

                        
 

                        
   Each
                              entry SHALL contain:
                        
 

                        
     -
                              the URI associated to this OCSP Responder,
                              from which the OCSP 
                        
       requests

                              are received, 

                        
 

                        
     -
                              the DN from a CA,

                        
 

                        
     -
                              an issuing public key from a CA,

                        
 

                        
     -
                              the method(s) used to know for which
                              subset of certificates =


                        
       issued

                              by the CA it is responsible for, <=
/span>

                        
 

                        
     -
                              the method(s) used to obtain the
                              revocation status of that <=
/b>

                        
       subset

                              of certificates issued under that CA
                              issuing public key,
=

                        
 

                        
     -
                              an OCSP certificate, 
                        
 

                        
     -
                              the OCSP public key contained in that OCSP
                              certificate, and

                        
 

                        
     -
                              the method used to gain access and sign
                              with the OCSP private <=
/p>
                        
       key

                              corresponding to that OCSP certificate.<=
/o:p>

                        
 

                        
   For
                              a given URI value, the OCSP Responder
                              SHALL only use one OCSP 

                        
   key
                              pair value.&nb=
sp;
                              Therefore there cannot be two
                              entries with the 

                        
   same
                              URI value and a different OCSP public key
                              value.

                        
 

                        
   NOTE:
                              a BasicOCSPResponse can only be signed
                              using a single private =


                        
       =
  key.
                              

                        
 

                        
   The
                              OCSP certificate SHALL be signed by the CA
                              issuing private key 
                        
   which

                              corresponds to the issuing CA public key
                              that is in this 

                        
   entry.

                        
 

                        
   When
                              it receives an OCSP request, the OCSP
                              responder SHALL handle =


                        
   exceptions

                              according to section 2.3. <=
/b>

                        
 

                        
   If
                              the OCSP request contains the name of a
                              requestor, the OCSP 
                        
   responder

                              SHALL verify whether there exists a
                              locally defined rule 
                        
   which

                              regulates access control.  If
                              this rule exists, it SHALL be 

                        
   followed.

                        
 

                        
   For
                              each target certificate, the OCSP
                              Responder SHALL verify =


                        
   whether
                              both the hash of the issuer's DN and the
                              hash of the issuer 
=

                        
   public
                              key which are present in the OCSP request
                              match with those 

                        
   from
                              an entry.

                        
 

                        
   When
                              there is no match, then the OCSP Responder
                              SHALL indicate the 
=

                        
   "unknown"

                              status and proceed with the next target
                              certificate from 

                        
   the
                              OCSP request.

                        
 

                        
   When
                              there is a match, the OCSP Responder SHALL
                              use the serial 

                        
   number
                              of the target certificate this is present
                              in the OCSP 

                        
   request
                              to determine the revocation status of that
                              certificate 

                        
   according
                              to the method(s) indicated in the entry. 

                        
 

                        
   When
                              the revocation status is provided by the
                              server using a real 
                        
   time
                              access to a database of revocation
                              statuses of issued 
=

                        
   certificates,

                              then the thisUpdate field SHALL be present
                              in the

                        
   SingleResponse


                              response whereas the nextUpdate field
                              SHALL be 

                        
   missing.
                              

                        
 

                        
   Otherwise,

                              both the thisUpdate and the nextUpdate
                              fields SHALL be 

                        
   present
                              in the SingleResponse. =


                        
 

                        
   The
                              time at which this response will be signed
                              MUST be indicated in 
                        
   the
                              producedAt field from the SingleResponse.

                        
 

                        
   If a
                              singleRequestExtensions is present in the
                              request it MUST be 
=

                        
   processed.<=
/span>

                        
 

                        
   If
                              there is another target certificate
                              present in the request, it =


                        
   SHALL
                              be processed in the same way.

                        
 

                        
   If a
                              requestExtensions is present in the
                              request it SHALL be 
                        
   processed.<=
/span>

                        
 

                        
   The
                              OCSP response MUST be signed using the
                              OCSP private key.

                        
 

                        
   Unless
                              there is a local rule which states
                              differently, for every =


                        
   target

                              certificate which matches both with the
                              hash of a CA DN and an =


                        
   issuing

                              public key from an entry, the OCSP
                              certificate of that entry <=
/b>

                        
   SHALL
                              be placed in the certs field.

                        
 

                        
   It
                              may happen, that none of the target
                              certificates from the OCSP<=
/b>

                        
   request

                              matches both with the hash of a CA DN and
                              an issuing public 

                        
   key
                              from an entry.=
  In
                              that case and unless a local rule states 

                        
   differently,

                              the certs field from the BasicOCSPResponse
                              SHOULD be 

                        
   kept
                              empty (to limit the disclose of the names
                              of the CAs from which <=
/p>
                        
   the
                              OCSP Responder received a delegation
                              from).

                        
 

                        
1.3. Processing by a locally
                              trusted Responder

                        
 

                        
   For
                              each CA for which the locally trusted
                              Responder is 

                        
   authoritative,

                              the OCSP Responder SHALL maintain a list
                              of entries. 

                        
 

                        
   Each
                              entry SHALL contain:
                        
 

                        
     -
                              the URI associated to this OCSP Responder,
                              from which the OCSP 
                        
       requests

                              are received, 

                        
 

                        
     -
                              the DN from a CA,

                        
 

                        
     -
                              an issuing public key from a CA,

                        
 

                        
     -
                              the method(s) used to know for which
                              subset of certificates =


                        
       issued

                              by the CA it is responsible for, <=
/span>

                        
 

                        
     -
                              the method(s) used to obtain the
                              revocation status of that <=
/b>

                        
       subset

                              of certificates issued under that CA
                              issuing public key,
=

                        
 

                        
     -
                              the method used to gain access to the
                              private key in order to 

                        
       sign
                              the OCSP response. 
=

                        
 

                        
   For
                              a given URI value, the OCSP Responder
                              SHALL only use one private =


                        
   key.  Therefore

                              there cannot be two entries with the same
                              URI value 

                        
   and
                              a different method to gain access to the
                              appropriate private key.

                        
 

                        
   NOTE:
                              a BasicOCSPResponse can only be signed
                              using a single private =


                        
       =
  key.
                              

                        
 

                        
   When
                              it receives an OCSP request, the OCSP
                              responder SHALL handle =


                        
   exceptions

                              according to section 2.3. <=
/b>

                        
 

                        
   If
                              the OCSP request contains the name of a
                              requestor, the OCSP 
                        
   responder

                              SHALL verify whether there exists a
                              locally defined rule 
                        
   which

                              regulates access control.  If
                              this rule exists, it SHALL be 

                        
   followed.

                        
 

                        
   For
                              each target certificate, the OCSP
                              Responder SHALL verify =


                        
   whether
                              both the hash of the issuer's DN and the
                              hash of the issuer 
=

                        
   public
                              key which are present in the OCSP request
                              match with those 

                        
   from
                              an entry.

                        
 

                        
   When
                              there is no match, then the OCSP Responder
                              SHALL indicate the 
=

                        
   "unknown"

                              status and proceed with the next target
                              certificate from 

                        
   the
                              OCSP request.

                        
 

                        
   When
                              there is a match, the OCSP Responder SHALL
                              use the serial 

                        
   number
                              of the target certificate this is present
                              in the OCSP 

                        
   request
                              to determine the revocation status of that
                              certificate 

                        
   according
                              to the method(s) indicated in the entry. 

                        
 

                        
   When
                              the revocation status is provided by the
                              server using a real 
                        
   time
                              access to a database of revocation
                              statuses of issued 
=

                        
   certificates,

                              then the thisUpdate field SHALL be present
                              in the

                        
   SingleResponse


                              response whereas the nextUpdate field
                              SHALL be 

                        
   missing.
                              

                        
 

                        
   Otherwise,

                              both the thisUpdate and the nextUpdate
                              fields SHALL be 

                        
   present
                              in the SingleResponse. =


                        
 

                        
   The
                              time at which this response will be signed
                              MUST be indicated in 
                        
   the
                              producedAt field from the SingleResponse.

                        
 

                        
   If a
                              singleRequestExtensions is present in the
                              request it MUST be 
=

                        
   processed.<=
/span>

                        
 

                        
   If
                              there is another target certificate
                              present in the request, it =


                        
   SHALL
                              be processed in the same way.

                        
 

                        
   If a
                              requestExtensions is present in the
                              request it SHALL be 
                        
   processed.<=
/span>

                        
 

                        
   The
                              OCSP response MUST be signed using the
                              OCSP private key.

                        
 

                        
   The
                              certs field may contain no, one or several
                              OCSP certificates 

                        
   according
                              to local rules followed by the locally
                              trusted Responder.

                      

                  

                

              
              


              

              
Not broken.

              


              

              
/Stefan

              


              

              
                

                  

                    

                        
 
                        
 
                        
End
                            of comments

                          

                        


                          Denis

                      

                  

                

              

          

        

      

    

    

  

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/m=
ailman/listinfo/pkix


--B_3444825885_27912951--



From stefan@aaa-sec.com  Wed Feb 27 17:19:38 2013
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 2930721F8AE6 for ; Wed, 27 Feb 2013 17:19:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
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 Wkik45m4knHV for ; Wed, 27 Feb 2013 17:19:36 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id BA77F21F8814 for ; Wed, 27 Feb 2013 17:11:09 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 703B54C06E2 for ; Thu, 28 Feb 2013 02:01:34 +0100 (CET)
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 EJjBTUiLf54D for ; Thu, 28 Feb 2013 02:01:01 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D70DF4C08D7 for ; Thu, 28 Feb 2013 02:00:50 +0100 (CET)
Received: (qmail 10088 invoked from network); 28 Feb 2013 01:00:42 -0000
Received: from 81-236-19-140-no39.tbcn.telia.com (HELO [192.168.1.69]) (stefan@fiddler.nu@[81.236.19.140]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 28 Feb 2013 01:00:42 -0000
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Thu, 28 Feb 2013 02:00:41 +0100
From: Stefan Santesson 
To: Denis Pinkas 
Message-ID: 
Thread-Topic: [pkix] Review of 2560-bis draft 8. Answer to WGLC
In-Reply-To: <5118FDAB.5080804@bull.net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3444861647_28902524"
Cc: pkix 
Subject: Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC
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, 28 Feb 2013 01:19:40 -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_3444861647_28902524
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Denis,

My replies in line;

From: Denis Pinkas 
Date:  Monday, February 11, 2013 3:18 PM
To  Stefan Santesson 
Cc:  Stephen Kent , pkix 
Subject:  Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC

>   =20
> =20
>  =20
>=20
> Stefan,
> =20
> =20
> =20
> I have finally reviewed your disposition of comments. I have used draft 1=
3.
> =20
> =20
> =20
> I will not address the comments in sequence, but I will consider four
> categories:
> =20
> =20
> =20
> Category 1) Some comments which seem to be solved. Yes indeed, they may b=
e a
> few of them !
> =20
> =20
> =20
> Category 2) Some comments which might possibly be solved at the WG level.
> =20
>=20
> =20
> Category 3) Some comments that I will address at the IETF lastcall level,
> rather than the WG last call level, since I disagree
>  that t is =B3new ways to say the same thing=B2 andit is likely to be a waste=
 of
> time for both of us to argue again at the WG level
>  (these cmments are commented as =B3not broken=B2).
> =20
> =20
> =20
> Category 4) Some typos and edtorials found while reading draft 13.
> =20
> =20
> =20
> =20
> =20
> CATEGORY 1
>=20
> =20
> =20
> Comment 4 (was editorial).
> =20
> =20
> =20
> Comment 5.
> =20
> =20
> =20
>Comment 6.=20
> =20
> =20
> =20
> Comment 19. Solved, since =B3unknown=B2 seems now to be also allowd for
> non-issued certificates
>  (even if the OCSP responder is using a direct ccess to the certificate
> database). See comment 8.
> =20
> =20
> =20
> Comment 13: Aceptable, since the text uses =B3MAY=B2.
> =20
> =20
> =20
> Comment 18.=20
> =20
> =20
> =20
> Comment 22.
> =20
> =20
> =20
> Comment 23.
> =20
> =20
> =20
> Comment 28.
> =20
> =20
> =20
> CATEGORY 1
> =20
> =20
> =20
> Comment 8: You have change the meaning of the revoked state in a way that=
 is
> not what I requested.> =20
> =20
> =20
> The original text was:
> =20
> =20
> =20
>    The "revoked" state indicates that the certificate has been revoked
> =20
>    (either permanantly or temporarily (on hold)).
> =20
> =20
> =20
> The new text is:
> =20
> =20
> =20
>    The "revoked" state indicates thatthe certificate has been revoked
> =20
>    either permanentl or temporarily on hold (i.e. the revocation reason
> =20
>    is certificateHold).
> =20
> =20
> =20
> Bydoing this, you do not llow any other case in the future to have a
> temporary revocation: =B3temporarilyon hold=B2
>  is not the same as =B3temporarily revoked=B2.
> =20
> =20
> =20
> I propose the following rewording:
> =20
> =20
> =20
>    The "revoked" state indicates that the certificate has been revoked
> =20
>    either permanently or temporarily (e.g. placed on hold).
> =20

I substituted "temporarily on hold" with "temporarly. The rest unchanged
since the only existing reason code for temporary revocation is
certificaeHold.


>=20
> =20
> The way the text from draft 13 is now written seems to allow using either
> =B3unknown=B2 or =B3revoked=B2 for non-issued certificates.
>  If this is the intent, then the good news is that this does not come any=
more
> into conflict with the French rules which apply for
>  the Administration since OCSP responders from CAs used by the French
> Ministries having a direct access tothe database
>  of issued certificates will be able to use =B3unknown=B2, rather than =B3revok=
ed=B2
> and the reason code =B3onhold=B2.
> =20
> =20
> =20
> However, the current text is still mandating the use of Extended Revoked
> Definition, but the ratonal for its need it is very poor.
>  As I have said on the PKIX list, the fact that the revocation date is Ja=
nuary> 1rst, 1970 is fully sufficient to know that we are in that
>  very special case and you have not provided a rational to say the contra=
ry.
> =20

I have. And I have pointed you to the minutes of the last PKIC meeting.
The consensus of the WG is t have the extension for just those reasons.

As implementer, I don't like heuritics. A date of Jan 1st 1970 may indicate
this behaviour, but may just be a misconiguration. It is not an explicit
statement.

> =20
> =20
> So we could get rid of it, =8A but the text from section 4.4.8 states:
> =20
> =20
> =20
>    This extension MA be present in other responses to signal that the
> =20
>    responder implementsthe extended revoked definition in section 2.2.
> =20
> =20
> =20
> I have difficulties to undersand what is really meant there (=B3other
 responses=B2 ?), since the text states:
> =20
> =20
> =20
>    This extension indicates that the reponder supports the extended
> =20
>    definition of the "revoked" status to also include non-issued
> =20
>    certificates according to section 2.2.
> =20
> =20
> =20
> Sinc both =B3unknown=B2 and revoked=B2 can be used, it would be desirable to be
> able to include the same extension in both cases,
>  but in that case that extension should be renamed.
> =20

This extension canbe included in all responses to signal that a responder
implements the expandeddefinition of revoked.
Doing so makes this fact auditable without having to ask for a non-issued
cert.

>=20
> =20
> I would propse to rename it: "non-issued certificate=B2 which means that th=
e
> associated A has no record of ever having issued
>  a certificate with the certificate serialnumber in the request (I still
> consider it as unnecessary in the case of =B3revoked=B2, but it would be
>  very useful in the ase of =B3unknown=B2). Of course, the text from section 4=
.4.8
> would need to be revisd.
> =20
> =20
> =20
> I propose the following:
> =20
> =20
> =20
> 4.4.8  Non-issued cetificate extension
> =20
> =20
> =20
>    This extension MUST be included in the OCSP response when the OCSP
> =20
>    responder knows that the CA identified in he request has no record
> =20
>    of ever having issued a certificate with the cetificate serial
> =20
>    number indicated in the request.
> =20
> =20
> =20
>   Clients do not have to parse this extension in order to determine
> =20
>    the status of certificates in responses.
> =20
> =20
> =20
>    This extension is identified by the object identifir id-pkix-ocsp-
> =20
>    non-issued-cert.
> =20
> =20
> =20
>      id-pkix-ocsp-nn-issued-cert OBJECT IDENTIFIER ::=3D {id-pkix-ocsp 9}
> =20
> =20
> =20
>    The value o the extension SHALL be NULL. This extension MUST NOT be
> =20
>    marked critial.
> =20
> =20
> =20
> Then the text on page 8 would need to be rearranged.
> =20
> =20

Your extensio  variant is a significant change to what has been agreed.
Your extension would ned to be a single response extension, and can't be
used to audit the behaviour of the OCSP responder unless you send a request
for a non-issued cert.
e want to avoid sending such fake requests for audit purposes as it may
interfre with systems at the responder trying to detect existence of rouge
certificaes.

This is a type of change that I can't make unless you get support from amaj=
ority of the WG for the change of direction you propose.

> =20
>=20
> The curent text is:
> =20
> =20
> =20
>    This state MAY also be returned if the
> =20
>   associated CA has no record of ever having issued a certificate with
> =20
>   the certificate serial number in the request, using any current or
> =20
>    previous issuing key (reerred to as a "non-issued" certificate in
> =20
>    this documnt).
> =20
> =20
> =20
>    The "unknown" state indicates that the responder doesn't know about
> =20
>    the certificate being requested.
> =20
> =20
> =20
>    NOTE: The "revoked" state for known non-issued certificate serial
> =20
>          numbes is allowed in order to reduce the risk of relying
> =20
>          parties using RLs as a fall back mechanism, which would be
> =20
>          considerably highe if an "unknown" response was returned.
> =20
> =20
> =20
>    When a responder responds revoked to a status request for anon-
> =20
>    issued certificate, the responder MUST include the extended revokd
> =20
>    definition response extension (section 4.4.8) in the response,
> =20
>    indicating that the OCSP responer supports the extended definition
> =20
>    of revoked state to also cover non-isued certificates. In addition,
> =20
>    the SingleResponse related to this nonissued certificate;
> =20
> =20
> =20
>     - MUST provide the revocation reason cerificateHold (6),
> =20
> =20
> =20
>     - MUST specify the revocationTime January 1, 1970, and;
> =20
> =20
> =20
>     - MUS NOT include a CRL References extension (section 4.4.2) or any
> =20
>       CRL Enry Extensions (section 4.4.5).
> =20
> =20
> =20
> Proposed text for a replacement:
 =20
> =20
> =20
>    The "unknown" state indicates that the responder doesn't know bout
> =20
>    the certificate being requested.
> =20
> =20
> =20
>    If the OCSP responder knows that CA identified in the request has
>  >    no record of ever having issued a certificate with the certificate
> =20
>    serial number in the request, using any current or previus issuing
> =20
>    key (referred to as a "non-issued" certificate in this documet),
> =20
>    the OCSP responder SHALL respond either =B3revoked =B3 or =B3unknown=B2.
> =20

This is unfortunately very common n your rewording efforts. When trying to
fix one thing, you create new even bgger problems.

An infrastructure that provides reproduced responses will respond
"unauthorized". This text may be interpreted to interfer with such
operations.
Further, and worse. This is not backwards compatible. Curent OCSP
responders may respond "good" even if they have access to CA records.
> =20
> =20
>    Note: The "revoked" state for known non-issued certificate serial
>=20
>    numbers is allowed in order to reduce the risk of relying parties
> =20
>    using CRLs as a fall back mechanism, which would be possible when
> =20
>    he "unknown" response is returned.
> =20
> =20
> =20
>    When a responder responds revoked or unknown to a status request
> =20
>    for a non-issued certifiate, the responder MUST include the
> =20
>    non-issued certificate extension (see section 4.4.8) in the
> =20
>    response.=20
> =20
> =20
> =20
>    When a responder esponds revoked to a status request for a non-
> =20
>    issued certificate, in addition, the responder:
> =20
> =20
>=20
>     - MUST provide the revocation reason certificateHold (6),
> =20
> =20
>  >     - MUST specify the revocationTime January 1, 1970, and;
> =20
> =20
> =20
>    - MUST NOT include a CRL References extension (section 4.4.2) or any
> =20
>       CRL Entry Extensions (section 4.4.5).
> =20
>=20
> =20
> =20
> Finally, the last bulet on page 4 should be reworded:
> =20
> =20
> =20
> Current text:
> =20
> =20
> =20
>      o Section 4.4.8 specifies a new extension that indicates that the
> =20
>          responder supports the extended use of the "revoked" response
> =20
>          for non-isued certificates defined in section 2.2.
> =20
> =20
> =20
> Proposed replacement text
> =20
> =20
> =20
>       o  Section 4.4.8 specifies a new extension that indicates that
> =20
>          the OCSP responder knows that CA identified in the requst
> =20
>          has no record of ever having issued a ertificate with the
> =20
>          certificate serial number present in the request, as defind
> =20
>          in section 2.2.
> =20
> =20

No. Again, this changes the scope of theextension and its audit properties.
Such change requres WG consensus.


> =20
>=20
> Comment 9: Solved, if the comment above may be solved.
 =20
> =20
> =20
> Comment 20:  This comment is preliminary classified by you as =B3not boken=B2=
.
> However, since you asked: =B3If you don=B9t replace 4.2.2.3,
>  then what really are you missing ?=B2, I will provide you with an answer.
> =20
>=20
> =20
> This is the wrong way to state the question. Providing an ASN.1 syntaxas =
in
> 4.2.1 is not enough: the use of every parameter
>  MUST be explainedusing English words. So if you explain the use of every
> parameter after the dscription of the ASN.1 syntax
>  in section 4.2.1. then section 4.2.2.3 is no ore needed and thus can be
> deleted.
> =20
> =20
> =20
> The answer to your question =B3what is really missing=B2 is a descrition of t=
he
> use of every parameter listed in the ASN.1 in section 4.2.1
> =20
> =20

here are sufficient descriptions in he subsections following the ASN.1
description. Your change proposals are not compatible withthe minimalistic
approach adopted by the WG.


> =20
>=20
> Comment 21.
> =20
> =20
> =20
> While I can agree in general with the intent of the text, I d not underst=
and
> the first sentence of the Note which speaks of =B3CA key rollove=B2
>  and is copied below:
> =20
> =20
> =20
>    Note: CA key rollover is not prohibted when issuing a certificate
> =20
>          for an authorized responder for backwards compatibility with
> =20
>          RFC 256 [RFC2560]. That is, it is not prohibited to issue a
> =20
>          certificte for an authorized responder using a different
> =20
>          issuing key than the key used to issued the certificate being
> =20
>          checkedfor revocation. However, such practice is strongly
> =20
>          discouraged since clients are not required to recognize a
> =20
>          responder with such certiicate as an authorized responder.
> =20
> =20
> =20
> I would propose to delete it, sinc it does not add anything and thus to h=
ave:
> =20
> =20
> =20
>    Note: For backwards ompatibility with RFC 2560 [RFC2560], it is
> =20
>          not prohibited to isse a certificate for an authorized
> =20
>          responder using a different issing key than the key used to
> =20
>          issued the certificate being checked fr revocation.
> =20
>          However, such practice is strongly discouraged since clients
>  >          are not required to recognize a responder with such
> =20
>          cerificate as an authorized responder.
> =20

I agree, your text is better. Updated.
> =20
> =20
> Comment 24: The ASN.1 module in annex B.1 is still wrong, since it des no=
t
> define NoCheck.=20
> =20
> =20

No you are wrong. We have confirmed with sveral ASN.1 experts that
definitionf NoCheck is not necessary to define null content.
The current definition is perfectly vaid ASN.1

> =20
>=20
> Comment 26: You asked for explanations. Let me provide yo with an example
> when CRLs are being used by the OCSP responder
>  in the background. The OCSP responder needs to make sure hat the CRL it =
uses
> is valid. If it is simply using published CRLs
>  (i.e. no rusted link with the CA), it needs to make sure that the CA whi=
ch
> has issued te CRL has no been revoked.
> =20
> =20

No, this is a misstatement. You don't reoke CAs. You revoke CA
certificates. There might be a CA certificate that has been revoked fo a
reason that does not affect the OCSP responder.
These are operational policies that are outside the scope of the protocol.

The proposed text in comment 26 is plan wrong, or at least misleading. The
OCSP responder does not have to validate the CRL up to any particular root.
It may for example have been configure to directly trust the public key
used to validate the CRL.


> =20
>=20
> In Frace, there is a root CA for the Administration. However, the use of =
that
> root CA is optional. Thus a Ministry may have its own root,
>  but may also have its key certified by the rot CA of the Administration.=
 The
> OCSP responder may use the root CA of the inistry,
>  while a relying party may use the root CA of the Administration (or the
> reverse) to validate the CRL for the target certificate.
>  Thus the revocation stats will be different if the certificate of the CA=
 of
> the Ministry s revoked by the root CA of the Administration.
> =20
> =20

Which reinforces my poit. How the OCSP responder is configured to trust its
information source is outside the scope of the protocol.

The OCSP protocol never claims to provide the same conclusion about
revocation than another source th relying party may use.

I skip category 3 as this will be dealt with in IESG ast call.


> =20
>=20
> CATEGORY 3
> =20
> =20
> =20
> Comments 2, 3, 7, 10, 12, 14, 15,16, 17, 25 and 27.
> =20
> =20
> =20
> =20
> =20
> CATEGORY 4
> =20
> =20
> =20
> Page 4. The indentation of the bullets in section 1 is not uniform.
>  Bullets 1, 4, 5 and 9 have problems.
> =20
> =20
> =20
> Page 4. he fact that there is now an Annex B.2 dealing with the 2008 ASN.=
1
> syntax is missing. This should be added.
> =20
> =20
>=20
> Page 10. Change =B3Se further section .2.2.2=B2 into =B3See further section
> 4.2.2.2=B2
> =20
> =20


Thanks. I have fixed them all.

/Stefan

>=20
>  Denis
> =20
> =20
> =20
> =20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=20
> =20
> =20
> =20
> =20
>> =20
>> Denis,
>> =20
>>=20
> =20
>> =20
>> Responding to your comments below.
>> =20
>>=20
>> =20
>> =20
>> However, one genera remark to make recurring comments easier to understa=
nd.
>> =20
>>=20
>> =20
>> =20
>> Th WG decided to adopt a minimalistic approach to updating RFC 2560. Tha=
t
>> means that=20
>> =20
>> 1. We don't chane anything from RFC 2560 unless it is broken, or the
>> industry clearly need clarifications in order to avoid interoperability
>> issues.=20
>> 2. W retain the document structur of RFC 2560 as much as possible to all=
ow
>> easy comparison of what the changes are in coparison with RFC 2560.
>> =20
>>=20
>> =20
>> =20
>> One can always thik up more clever ways to write things out in words. Bu=
t
>> that also comes with a risk.
> =20
>> The current words has been around for a long time and we know from exper=
ince
>> which words worked to produce working implementations, and which did not
>> =20
>> Introducing new ways to say the same thing may introduce new problems an=
d
>> people might disagree on whatthe new perfect wording should be. And this
>> could go on forever.
>> =20
>>=20
>>  >> =20
>> So when my reply is "Not broken", then that is because the current ordin=
g
>> does not have such problems that is merits a change.
>> =20
>>=20
>> =20
> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>> From:  Denis Pinkas 
>>  Date:  Sunday, January 20, 2013 5:12 PM
>>  To:  Stefan Santesson , Stephen Kent 
>>  Cc:  pkix >>  Subject:  Re: [pkix] Review of 2560-bis dr=
aft 8. Answer to WGLC
>> =20
> =20
>>=20
>> =20
>> =20
>>> =20
>>>  =20
>>>   =20
>>>=20
>>> Please find 32 comments on draft-ietf-pkix-rfc2560bis
>>> =20
>>> =20
>>> =20
>>> 1. The document states:
>>>=20
>>>  > separately>
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Responded to separately.
>>=20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 2. Te current text from section 2 states:
>>> =20
>>> =20
>>> =20
>>> 2.  rotocol Overview
>>> =20
>>> =20
>>> =20
>>>    In lieu of or as a supplement to checking against  periodic CRL, it
>>> =20
>>>    may be necessary to obtain timely information regrding the
>>> =20
>>>    revocation status of a certificate (cf. RFC5280], Section 3.3).
>>> =20
>>>    Examples include high-vaue funds transfer or large stock trades.
>>> =20
>>> =20
>>> =20
>>>    The Online Certficate Status Protocol (OCSP) enables applications to
>>> =20
>>>    determine te (revocation) state of an identified certificate OCSP
>>> =20
>>>    may be used to satisfy some of the operational requirements of
>>> =20
>>>   providing more timely revocation information than is possible with
>> =20
>>>    CRLs and may also be used to obtain additional status information.
>>> =20
>>> =20
>>> =20
>>> This text is misleading because readers may think thatOCPS necessarily
>>> provides =B3timely information=B2.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> "may" doe not mean "necessarily".
>> =20
>>=20
>> =20
>>   >>> =20
>>> =20
>>> =20
>>> Proposed text replacement:
>>> =20
>>> =20
>>> =20
>>>=20
>>>    The Online Cerificate Status Protocol (OCSP) is a client-server
>>> =20
>>>    protocol which enables applications to obtain the revocation status
>>> =20
>>>    of oneor more certificates either "good", "revoked", or "unknown".
>>> =20
>>> =20
>>> =20
>>>    The revocation status may be rovided by the server either using a
>>> =20
>>>    real time access to a database of issued certificates, or using a
>>> =20
>>>    batchaccess to a database of issued certificates, or using a
>>> =20
>>>    real time access to a database of revocation statuses of issued
>>> =20
>>>    certificates, or using a batch access to a database of revocation
>>> =20
>>>    statuses of issued certificates, or using CRLs, or using=20
>>> =20
>>>    combination of base CRLs and delta CRLs.
>>> =20
>>>  >>> =20
>>>    In the first case, it is possible to obtain timely revocation status
>>> =20
>>>    information, whereas in the other cases, the frehness of the
>>> =20
>>>    revocation staus is not better than the mechanisms it is based on.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 3. The current text frm section 2 states:
>>> =20
>>> =20
>>> =20
>>>    An OCSP cliet issues a status request to an OCSP responder and
>>> =20
>>>    Suspends acceptance of te certificate in question until the
>>> =20
>>>    responder provides a response.
>>> =20
>>> =20
>>> =20
>>>    This protocol specifies th data that needs to be exchanged between
>>> =20
>>>    an application checking the status of a certificate and the server
>>> =20
>>>    providing that status.
>>> =20
>>> =20
>>> =20
>>> Tus is insufficient for an overview. More details are needed to know wh=
at
>>> the document provides,
>>> in particular that the request may contain severl requests for several
>>> certificates issued by different CAs.
>>> The possbility of using extensions should also be advertised.
>>> =20
>>> =20
>>> =20
>>> Proposed text replacement:
>>> =20
>>> =20
>>> =20
>>>    When using OCSP, an OCSP client ssues a certificate revocation
>>> =20
>>>    status request to an OCSP responder for one or more certificates
>>> =20
>>    issued by the same CA or for one or more certificates issued by
>>> =20
>>    different CAs and then suspends acceptance of the certificate(s)
>>> =20
>>>    in question until the respondr provides a response.
>>> =20
>>> =20
>>> =20
>>>    Ths document specifies the data that needs to be exchanged between
>>> =20
>>>    an applicaion checking the status of a certificate and the server
>>> =20
>>>    providing tat status.
>>> =20
>>> =20
>>> =20
>>>    OCSP may also provide additional status infrmation using
>>> =20
>>>    extensions.=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not roken
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 4. Page 6. Editorial. Punctution and a CR/LF are missing.
>>> =20
>>> =20
>>> =20
>>> The text states:
>>> =20
>>>=20
>>> =20
>>>    3. the request contains the information needed by the responder If
>>> =20
>>>       any one of the prior coditions are not met, the OCSP responder
>>> =20
>>>       produces an error messag; otherwise, it returns a definitive
>>> =20
>>>       response.
>>> =20
>>> =20
>>> =20
>>> It should state:
>>> =20
>>> =20
>>>  >>>    4. the request contains the information needed by the responder=
.
>> =20
>>> =20
>>> =20
>>>       If any one of the prior conditions are not met, theOCSP responder
>>> =20
>>>       produces an error message; otherwse, it returns a definitive
>>> =20
>>>       response.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>> =20
>>  =20
>>=20
>> =20
>> =20
>> Fixed in draft 10.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>> =20
>>> =20
>>>=20
>>> 5. On page 7, the text states:
>>> =20
>>> =20
>>> =20
>>>    All definitive response messages SHALL be digitally signed. The key
>>> =20
>>>   used to sign the response MUST belong to one of the following:
>>> =20
>>> =20
>>> =20
>>>    -  the CA who issued th certificate in question
>>> =20
>>>    -  a Tusted Responder whose public key is trusted by the requester
>>> =20
>>>    -  a CA Designated esponder (Authorized Responder) who holds a
>>> =20
>>>       specially marked certificate issued directly by the CA, indicatin=
g
>>> =20
>>>       that th responder may issue OCSP responses for that CA.
>>> =20
>>> =20
>>> =20
>>> The paragraph is ambiguous on several aspect.
>>> =20
>>> =20
>>> =20
>>> Delegation  is addressed in at least three different places, but with
>>> different terms and conditions.
>>>  f some one picks a sentence in one paragraph rather than another, it w=
ill
>>> lead to a different conclusion.
>>>  RFCs are supposed to be clear.
>>> =20
>>> =20
>>> =20
>>> On page 10, the current text staes in section 2.6 OCSP Signature Author=
ity
>>> Delegation states:
>>> =20
>>> =20
>>>  >>>    The key that signs a certificate's status information need not =
be the
>>>  >>>    same  key that signed the certificate. A certificate's issuer
>>> =20
>>>    explicitly delegates OCSP signing authority by issuing a certificate
>>> =20
>>>    containing a unique value for extendedKeyUsage in the OCS signer's
>>> =20
>>>    certificate. This certificate MUST be issued directly o the
>>> =20
>>>    responder by the cognizant CA.
>>> =20
>>> =20
>>> =20
>>> On page16, there is a section 4.2.2.2 called =B3Authorized Responders=B2
>>> dealing with thesame topic.
>>> =20
>>> =20
>>> =20
>>> Section 4.2.2.2 states:
>>> =20
>>> =20
>>> =20
>>>    The key that signs a certificate's status information need not be th=
e
>>> =20
>>>    same  key that signed the certificate. It is ecessary however to
>>> =20
>>>    ensure that the entity signing this information s authorized to do
>>> =20
>>>    so.  Therefore, a certificate's issuer MAY either sign the OCSP
>>> =20
>>>    responses itself or it MAY explicily designate this authority to
>>> =20
>>>   another entity.  OCSP  signing delegation SHALL be designated by the
>>> =20
>>>    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
>>> =20
>>>    extension included in the OCSP resonse signer's certificate.  This
>>> =20
>>>    certificateMUST be issued directly by the CA that issued the
>>> =20
>>>    certificate in question.
>> =20
>>> =20
>>> =20
>>>    The CA SHOULD use the same issuing key to issue a delegation
>>> =20
>>>    certificate as was used to sign the certificate being checked for
>>> =20
>>    revocation. Systems  relying on OCSP esponses MUST recognize a
>>> =20
>>>    delegation  certificate as being issued by the CA that ssued the
>>> =20
>>>    certificate  in question only if the delegation certificat and the
>>> =20
>>>    certificate  being checked for revocation was signed by the same key=
.
>>> =20
>>> =20
>>> =20
>>> The last sentence above in yellow is the key sentence that is issing in=
 the
>>> two other sections.
>>> =20
>>> =20
>>> =20
>>> Most implementations only support the case where the OCS Responder rece=
ives
>>> an OCSP certificate that i signed by the same key
>>> that was used to sign the target certificate. They do not suport the ca=
se
>>> where the OCSP Responder receives an OCSP certificate
>>> thatis signed by a key that is different from the one that was used to =
sign
>>> thetarget certificate.
>>> =20
>>> =20
>>> =20
>>> It is inappropriate to have three sections dealing with the same toic w=
ith
>>> a slightly different meaning.
>>> =20
>>> =20
>>> =20
>>> It is proposed th following.
>>> =20
>>> =20
>>> =20
>>> On page 7, after:
>>> =20
>>> =20
>>> =20
>>>    - a CA Designated Responder (Authorized Responder) who holds a
>>> =20
>>>       specially marked certificate issued directl by the CA, indicating
>>> =20
>>>       that the responder may issue OCSP responss for that CA.
>>> =20
>>> =20
>>> =20
>>> it is proposed to add =B3(see section 4.2.2.2 for further details)=B2, so t=
hat
>>> thereader knows that more details are provided later on.
>>> =20
>>> =20
>>> =20
>> Then we do not need two sections to address delegation which start with =
the>>> same sentence:=20
>>> =20
>>> =20
>>>=20
>>>  =B3The key that signs a ertificate's status information need not be the =
same
>>> key that signed the certificate=B2.
>> =20
>>> =20
>>> =20
>>> It is thus proposed to delete section 2.6.
>>> =20
>> =20
>>> =20
>>> Section 4.2.2.2 will thus remain the single section providing full deta=
ils.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>>I have added references to section 4.2.2.2 in the quoted sections in 2.2 =
and
>> 2.6.
>> =20
>> (will be included in raft 11)
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>> =20
>>> =20
>>> =20
>>> 6. Page 7, the text states:
>>> =20
>>>=20
>>> =20
>>> =20
>>>    A definitive reponse message is composed of:
>>> =20
>>> =20
>>> =20
>>>    -  version of the response syntax
>>> =20
>>>    -  name of the responder
>>> =20
>>>    -  responss for each of the certificates in a request
>>> =20
>>>    -  optional extensions
>>> =20
>>>    -  signature algorithmOID
>>> =20
>>>    -  signature computed across hash of the response
>>> =20
>>> =20
>>> =20
>>> This description does not fit with the ASN.1 sntax which is detailed la=
ter
>>> on, and in particular:
>>> =20
>>> =20
>>> =20
>>>    ResponseData ::=3D SEQUENCE {
>>> =20
>>>       version              [0] EXPLICIT Version DEFAULT v1,
>>> =20
>>>       respoderID              ResponderID,
>>> =20
>>>       producedAt               GeneralizedTime,
>>> =20
>>>       responses                SEQUENCE OF SingleResponse,
>>> =20
>>>       responseExtensions   [1] EXPLICIT Extensions OPTIONAL }
>>> =20
>>> =20
>>> =20
>>> Proposed text replacement:
>>> =20
>>> =20
>>> =20
>>>    A definitive response message is composed of:
>>> =20
>>> =20
>>> =20
>>>    - a rsponse status and if there is no error, the following:
>>> =20
>>    - the version of the response syntax,
>>> =20
>>>    - an identifier of the OCSP server,
>>> =20
>>>    - the time at which the response was produced,
>>> =20
>>>    - single responses for each of the target certificates,
>>> =20
>>>    - optional extensions,
>>> =20
>>>    - the signature algorithm OID,
>>> =20
>>>    - the signature computed across hash of the response, and
>>> =20
>>>    - optional certificates.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> This is an overview section. We ought not try to duplicate the level of
>> detail provided in the detailed protocol section.
>> =20
>> A "definitive response" according to tho 2.1 is a response to an error-f=
ree
>> request, so your first remark is redundant.
>> =20
>>=20
>> =20
>> =20
>> I have added a note about time to the current list, and changed "name" t=
o
>> identifier in bullet 2.
>> =20
>> (will be included in draft 11)
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 7. The text states on page 7:
>>> =20
>>> =20
>>> =20
>>>    The response for each of the certificates in a request consists of
>>> =20
>>> =20
>>> =20
>>>    -  target certificate identifier
>>> =20
>>>    -  certificate status value
>>> =20
>>>    -  response validity interval
>>> =20
>>>    -  optional extensions
>>> =20
>>> =20
>>> =20
>>> However,  there are no explanations for the purpose of these parameters=
 and
>>> how they should be processed.
>>> =20
>>> There are also no explanations on how to process a single response and =
how
>>> to verify that it is its presence within the signed structure
>>>  is valid or not valid. This is a major deficiency of the current
>>> description of RC 2560 where there is no explanation on how to validate
>>>  a single response.
>>> =20
>>> =20
>>> =20
>>> Text proposal to be added after:
>>> =20
>>> =20
>>> =20
>>>    The purpose of the identifier of the OCSP server is to allow OCSP
>>> =20
>>>    clients to find whether the definitive response was signed by a CA
>>> =20
>>>    or by an OCSP Responder.
>>> =20
>>> =20
>>> =20
>>>    The identifier of the OCSP server SHOULD either be the name or the
>>> =20
>>>    key from a CA, or the name or the key from a OCSP Responder.
>>> =20
>>> =20
>>> =20
>>>    Unless there exist local rules (which are outside the scope of this
>>> =20
>>>    document) for verifying that a single response is correctly signed,
>>> =20
>>>    the following applies:
>>> =20
>>> =20
>>> =20
>>>    When the identifier matches with the name of the CA which has issued
>>> =20
>>>    the target certificate or corresponds to the key used to issue the
>>> =20
>>>    target certificate, then a single response is correctly signed
>>> =20
>>>    only if the digital signature of the OCSP response is valid using th=
e
>>> =20
>>>    key used to sign the target certificate.
>>> =20
>>> =20
>>> =20
>>>    When the identifier does not match with the name of the CA which has
>>> =20
>>>    issued the target certificate or does not correspond to the key used
>>> =20
>>>    to issue the target certificate, then an single response is correctl=
y
>>> =20
>>>    signed only if :
>>> =20
>>> =20
>>> =20
>>>          (a) there exists in the response an OCSP certificate issued by
>>> =20
>>>              the CA which has issued the target certificate which is
>>> =20
>>>              signed by the same key as the one used to issue the
>>> =20
>>>              target  certificate, and
>>> =20
>>> =20
>>> =20
>>>          (b) the digital signature of the OCSP response is valid using
>>> =20
>>>              the  subjectPublicKey contained in this OCSP certificate.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>> All of this is already covered by the document.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 8. The text states on page 7:
>>> =20
>>> =20
>>> =20
>>>    The "revoked" state indicates that the certificate has been revoked
>>> =20
>>>    (either permanently or temporarily (on hold)). This state MAY also b=
e
>>> =20
>>>    returned if the responder knows that the requested certificate has
>>> =20
>>>    never been issued during the history of the associated CA using  any
>>> =20
>>>    current or previous issuing key.
>>> =20
>>> =20
>>> =20
>>> The text is ambiguous because there are two embedded parenthesis and it=
 is=20
>>> unclear whether the inner parenthesis means =B3i.e=B2 or =B3e.g=B2.=20
>>>  This single sentence may let think that on hold is the single case for=
=20
>>> temporarily revocation. Since neither X.509 nor RFC 5280 address=20
>>>  the case of a temporary revocation in the context of an OCSP response =
(but=20
>>> only in the context of CRLs), we are able to add another case=20
>>>  of temporary revocation which will only apply in the context of OCSP.
>>> =20
>>> =20
>>> =20
>>> The above sentence using the terms =B3never been issued during the histor=
y of=20
>>> the associated CA =B3does not capture the fact=20
>>>  that it could be issued in the future, hence why using =B3not yet been u=
sed=B2=20
>>> would be more appropriate.
>>> =20
>>> =20
>>> =20
>>> Finally, it would have been more logical to use =B3unknown=B2. So it is=20
>>> important to add a note to explain why we have chosen that case for =B3le=
gacy=20
>>> clients=B2,=20
>>>  otherwise the people who have not participate to the exchanges will no=
t=20
>>> understand.
>>> =20
>>> =20
>>> =20
>>> Proposed text replacement:
>>> =20
>>> =20
>>> =20
>>>    The "revoked" state indicates that the certificate has been revoked,
>>> =20
>>>    either permanently or temporarily.
>>> =20
>>> =20
>>> =20
>>>    A certificate may be temporarily revoked either because it is=20
>>> =20
>>>    placed on hold (i.e. the revocation reason is certificateHold) or=20
>>> =20
>>>    because the responder is able to know, using a positive list of=20
>>> =20
>>>    issued certificates, that the serial number from the requested=20
>>> =20
>>>    certificate has not yet been used by the CA to issue a certificate=20
>>> =20
>>>    (i.e. the revocation reason is notIssuedOrIrregularlyIssued).
>>> =20
>>> =20
>>> =20
>>> NOTE: The "revoked" state is used rather than the =B3unknown=B2 state, to
>>> =20
>>>       make sure that relying parties that were conformant to RFC 2560
>>> =20
>>>       will not use CRLs as a fall back mechanism.=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> I removed the double parenthesis and adopted your clarification with reg=
ard=20
>> to "on hold".=20
>> =20
>>=20
>> =20
>> =20
>> The text in draft 10 has changed from what you have commented on. I beli=
eve=20
>> that text is better.
>> =20
>>=20
>> =20
>> =20
>> You "Note" has problems.
>> =20
>> 1. We do not prevent responders to respond "unknown" if their assessment=
 is=20
>> that this is an appropriate response, considering what they know about t=
he=20
>> requested serial number. Thus the term "is used" is misleading.=20
>> 2. This mechanisms does not "make sure" that the clients do anything. It=
's up=20
>> to the discretion of the relying party to decide what source of revocati=
on=20
>> checking they rely on. This does however reduce the risk of clients fall=
ing=20
>> back to CRL:s=20
>> 3. This mechanism is not just relevant to old clients, but also to new o=
ne=20
>> for the same reason.=20
>> =20
>>=20
>> =20
>> =20
>> I have adopted a modified version of your Note:
>> =20
>>=20
>> =20
>> =20
>> =20
>>    NOTE: The "revoked" state for known non-issued certificate serial
>> =20
>>          numbers is allowed in order to reduce the risk of relying
>> =20
>>          parties using CRLs as a fall back mechanism, which would be
>> =20
>>          considerably higher if an "unknown" response was returned.
>> =20
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 9. The text states on page 8:
>>> =20
>>> =20
>>> =20
>>>    When a responder responds revoked to a status request for a non-
>>> =20
>>>    issued certificate, the responder MUST also;
>>> =20
>>> =20
>>> =20
>>>     - include the extended revoked definition response extension
>>> =20
>>>       (section 4.8), indicating that the OCSP responder supports the
>>> =20
>>>       extended definition of revoked state to also cover non-issued
>>> =20
>>>       certificates,
>>> =20
>>> =20
>>> =20
>>>     - provide the revocation reason certificateHold (6), and;
>>> =20
>>> =20
>>> =20
>>>     - specify the revocation date January 1, 1970.=20
>>> =20
>>> =20
>>> =20
>>> As already explained on the PKIX list, using the revocation reason=20
>>> certificateHold is not appropriate=20
>>>  because it changes the meaning of certificateHold.=20
>>> =20
>>> =20
>>> =20
>>> The extended revoked definition response extension is a means to signal=
 that=20
>>> it not a true certificate hold but a =B3not issued certificate=B2.=20
>>>  Legacy applications cannot take advantage of it.=20
>>> =20
>>> =20
>>> =20
>>> Some applications which handle non repudiation enter a waiting state wh=
en=20
>>> the revocation reason certificateHold is used thus=20
>>>  it is not appropriate to overload the meaning.
>>> =20
>>> =20
>>> =20
>>> It is possible to use another enumeration for signalling that specific =
case:
>>> =20
>>> notIssuedOrIrregularlyIssued  (7).
>>> =20
>>> =20
>>> =20
>>> Thus for new applications it would be much better to use=20
>>> notIssuedOrIrregularlyIssued (7) as already proposed on the PKIX list.
>>> =20
>>> =20
>>> =20
>>> The above sentence uses the text:=20
>>> =20
>>> =20
>>> =20
>>> =B3a status request for a non-issued certificate=B2=20
>>> =20
>>> =20
>>> =20
>>> whereas it would be more appropriate to state:=20
>>> =20
>>> =20
>>> =20
>>> =B3a status request for a serial number which has not been used by the CA=
 or=20
>>> used irregularly to issue a certificate=B2.
>>> =20
>>> =20
>>> =20
>>> Placing the ASN.1 description at such a place in the document is=20
>>> inappropriate since the ASN.1 structures have not yet been described.=20
>>> Thus only the functional aspects should be mentioned, but not the ASN.1=
=20
>>> implications.
>>> =20
>>> =20
>>> =20
>>> BTW, the description should follow the same order as the ASN.1. This is=
 not=20
>>> the case.=20
>>> =20
>>> =20
>>> =20
>>> This text should be deleted from this section and the appropriate text=20
>>> should be added when the parameters of the response are described.=20
>>> =20
>>> =20
>>> =20
>>> The text proposed in the previous comment should be sufficient at this =
time=20
>>> of reading.
>>> =20
>>> =20
>>> =20
>>> In addition, section 4.4.8  Extended  Revoked Definition should be dele=
ted.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> The referred text has been updates in draft 09.
>> =20
>>=20
>> =20
>> =20
>> This has been discussed on the list and you have yet to convince the lis=
t of=20
>> your new reason code.
>> =20
>> I disagree as the risk of running into problems with the deployed base o=
f=20
>> application is hugely larger with introduction of a new reason code, rat=
her=20
>> than using certificateHold.
>> =20
>> No application should be broken, since no application have business aski=
ng=20
>> for non-issued cert serial numbers in the first place. Secondly, no=20
>> application can assume that a certificateHold reason will be cleared any=
 time=20
>> soon.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 10. The text states on page 8:
>>> =20
>>> =20
>>> =20
>>> 2.4  Semantics of thisUpdate, nextUpdate and producedAt
>>> =20
>>> =20
>>> =20
>>> This section is misplaced. At this time of reading, the reader does not=
 know=20
>>> that thisUpdate, nextUpdate and producedAt are values=20
>>>  used by the ASN.1 structures. It is appropriate to describe what these=
s=20
>>> parameters mean when the ASN.1 syntax is described.=20
>>>  The current ASN.1 syntax is very badly described. One would expect tha=
t=20
>>> after every ASN.1 structure description every parameter is described.=20
>>>  Unfortunately this is not the case.=20
>>> =20
>>> =20
>>> The text from this section is not aligned with the text that is present=
 in=20
>>> section 4.2.2.1.=20
>>> =20
>>> =20
>>> =20
>>> In particular, in section 2.4:
>>> =20
>>> =20
>>> =20
>>>    If nextUpdate is not set, the responder is indicating that newer
>>> =20
>>>    revocation information is available all the time.
>>> =20
>>> =20
>>> =20
>>> While in section 4.2.2.1:
>>> =20
>>> =20
>>> =20
>>>    Responses where the nextUpdate value is not set are equivalent=20
>>> =20
>>>    to a CRL with no time for nextUpdate (see Section 2.4).
>>> =20
>>> =20
>>> =20
>>> It is not appropriate to have two different descriptions in two differe=
nt=20
>>> places.
>>> =20
>>> =20
>>> =20
>>> Delete section 2.4. See comment number 19 for the description of these=20
>>> parameters.
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>> The current text segments fits well into a protocol overview section.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 11. Section 2.5 is also misplaced. They use values from the ASN.1 synta=
x=20
>>> which has not yet been described.=20
>>>  They should be moved or incorporated in the document once the ASN.1=20
>>> description has been done.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 12. Remainder: Section 2.6 should be deleted (see comment number 5).
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 13. Section 2.7 states:
>>> =20
>>> =20
>>> =20
>>> 2.7  CA Key Compromise
>>> =20
>>> =20
>>> =20
>>>    If an OCSP responder knows that a particular CA's private key has
>>> =20
>>>    been compromised, it MAY return the revoked state for all
>>> =20
>>>    certificates issued by that CA.
>>> =20
>>> =20
>>> =20
>>> This section is misleading and should be removed. The reason is the=20
>>> following:
>>> =20
>>> =20
>>> =20
>>> The relying party must verify that the singleResponse is signed by a=20
>>> responder which is entitled to do so.
>>> =20
>>> =20
>>> =20
>>> a) If the CA key has been compromised and if the response is signed by =
that=20
>>> CA key then the singleResponse will be discarded=20
>>>  when performing the certification path validation whatever the content=
 of=20
>>> the response may be.
>>> =20
>>> =20
>>> =20
>>> b) If the CA key which has issued the OCSP certificate has been comprom=
ised=20
>>> and if the response is signed by the key present=20
>>>  in the OCSP certificate then the singleResponse will be discarded when=
=20
>>> performing the certification path validation
>>>  whatever the content of the response may be.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> Security  must be provided using the validation of the certification pa=
th.=20
>>> Thus it does not matter what the OCSP responder states.
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>> An OCSP responder does not have to be chained to the broken CA. The rely=
ing=20
>> party may have other trust configuration at choice.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>>=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 14. The text states on page 11:
>>> =20
>>> =20
>>> =20
>>> 3.2  Signed Response Acceptance Requirements
>>> =20
>>> =20
>>> =20
>>>    Prior to accepting a signed response as valid, OCSP clients SHALL
>>> =20
>>>    confirm that:
>>> =20
>>> =20
>>> =20
>>>    1. The certificate identified in a received response corresponds to
>>> =20
>>>       that which was identified in the corresponding request;
>>> =20
>>> =20
>>> =20
>>>    2. The signature on the response is valid;
>>> =20
>>> =20
>>> =20
>>>    3. The identity of the signer matches the intended recipient of the
>>> =20
>>>       request.
>>> =20
>>> =20
>>> =20
>>>    4. The signer is currently authorized to sign the response.
>>> =20
>>> =20
>>> =20
>>>    5. The time at which the status being indicated is known to be
>>> =20
>>>       correct (thisUpdate) is sufficiently recent.
>>> =20
>>> =20
>>> =20
>>>    6. When available, the time at or before which newer information wil=
l
>>> =20
>>>       be available about the status of the certificate (nextUpdate) is
>>> =20
>>>       greater than the current time.
>>> =20
>>> =20
>>> =20
>>> This section is misplaced since it uses terms from the ASN.1 syntax and=
 the=20
>>> protocol description has not yet been made,=20
>>>  since it is the next section 4. Its text is not correct either.=20
>>> =20
>>> =20
>>> =20
>>> This description does not take into account the fact that a=20
>>> BasicOCSPResponse may contain one or several SingleResponses.=20
>>>  In particular, the sentence =B3The signer is currently authorized to sig=
n the=20
>>> response=B2 is misleading because a signer=20
>>>  may be authorized to include some SingleResponses but not necessarily =
all=20
>>> of them.=20
>>> =20
>>> =20
>>> =20
>>> The appropriate explanations should be done after the description of th=
e=20
>>> response, when describing the processing of the response.
>>> =20
>>> =20
>>> =20
>>> Delete that section.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 15. On page 12, after the ASN.1 description, the only parameters which =
are=20
>>> described are:=20
>>> =20
>>> hashAlgorithm, issuerNameHash,  issuerKeyHash and serialNumber.
>>> =20
>>> =20
>>> =20
>>> This is insufficient.  In order to cover the full list of parameters, t=
he=20
>>> following text is proposed:
>>> =20
>>> =20
>>> =20
>>>    requestorName is optional and MAY be used by the server for access=20
>>> =20
>>>    control and audit purposes.
>>> =20
>>> =20
>>> =20
>>>    requestList contains one or more single requests.
>>> =20
>>> =20
>>> =20
>>>    requestExtensions is OPTIONAL.  Any  specific extension is OPTIONAL.
>>> =20
>>>    The critical flag SHOULD NOT be set for any of them. Section 4.4=20
>>> =20
>>>    suggests several useful extensions.  Additional extensions MAY be=20
>>> =20
>>>    defined in additional RFCs.
>>> =20
>>> =20
>>> =20
>>>    reqCert contains the identifier of a target certificate.
>>> =20
>>> =20
>>> =20
>>>    issuerNameHash is the hash of the Issuer's distinguished name.  The=20
>>> =20
>>>    hash shall be calculated over the DER encoding of the issuer's name=20
>>> =20
>>>    field in the certificate being checked.=20
>>> =20
>>> =20
>>> =20
>>>    issuerKeyHash is the hash of the Issuer's public key.  The hash=20
>>> =20
>>>    shall be calculated over the value (excluding tag and length) of the=
=20
>>> =20
>>>    subject public key field in the issuer's certificate.  The hash=20
>>> =20
>>>    algorithm used for both these hashes, is identified in=20
>>> =20
>>>    hashAlgorithm.=20
>>> =20
>>> =20
>>> =20
>>>       The primary reason to use the hash of the CA's public key in=20
>>> =20
>>>       addition to the hash of the CA's name, to identify the issuer,=20
>>> =20
>>>       is that it is possible that two CAs may choose to use the same=20
>>> =20
>>>       name (uniqueness in the Name is a recommendation that cannot be=20
>>> =20
>>>       enforced).  Two CAs will never, however, have the same public key=
=20
>>> =20
>>>       unless the CAs either explicitly decided to share their private=20
>>> =20
>>>       key, or the key of one of the CAs was compromised.
>>> =20
>>> =20
>>> =20
>>>    serialNumber is the serial number of the certificate for which=20
>>> =20
>>>    status is being requested.
>>> =20
>>> =20
>>> =20
>>>    singleRequestExtensions  is OPTIONAL.  Any  specific extension is=20
>>> =20
>>>    OPTIONAL.  The critical flag SHOULD NOT be set for any of them.=20
>>> =20
>>> =20
>>> =20
>>>    The requestor MAY choose to sign the OCSP request.  In that case, th=
e
>>> =20
>>>    signature is computed over the tbsRequest structure.  If the request
>>> =20
>>>    is signed, the requestor SHALL specify its name in the requestorName
>>> =20
>>>    field.  Also, for signed requests, the requestor MAY include
>>> =20
>>>    certificates that help the OCSP responder verify the requestor's
>>> =20
>>>    signature in the certs field of Signature.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>> The current text is short, but it is actually sufficient from the contex=
t of=20
>> the ASN.1 definitions of the section. This is a detailed protocol sectio=
n and=20
>> the reader need to understand ASN.1 in any case to understand and implem=
ent=20
>> the section.
>> =20
>> The information about criticality is already covered in the extension=20
>> section.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 16. Section 4.1.2 is called: =B3Notes on the Request Syntax=B2
>>> =20
>>> =20
>>> =20
>>> The first paragraph has been moved after the description of issuerKeyHa=
sh=20
>>> and thus is no more needed.
>>> =20
>>> =20
>>> =20
>>> The second paragraph has been moved after the description of=20
>>> requestExtensions.=20
>>>  However, the sentence=20
>>>  =B3 Unrecognized extensions MUST be ignored (unless they have the critic=
al=20
>>> flag set and are not understood)=B2=20
>>>  has been deleted since it applies to the OCSP responder and not to the=
 OCSP=20
>>> client. Thus it is no more needed.
>>> =20
>>> =20
>>> =20
>>> The third paragraph applies to signed requests. However, it should belo=
ng to=20
>>> a section dedicated on how clients should build OCPS requests,=20
>>>  which is currently missing. See the next comment.
>>> =20
>>> =20
>>> =20
>>> This section should be deleted.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 17. There should be a new section called: =B3Requirements  for OCSP clien=
ts=B2.=20
>>> =20
>>> =20
>>> =20
>>> It is important first to re-advertise that the request may be about sev=
eral=20
>>> certificates.=20
>>>  Thus it is important to describe the process for building a request, w=
hich=20
>>> is currently missing.
>>> =20
>>> =20
>>> =20
>>>    An OCSP request allows getting in the same response the revocation=20
>>> =20
>>>    status of one or more certificates.  In order to request the=20
>>> =20
>>>    status of one or more certificates in a single request, OCSP=20
>>> =20
>>>    clients SHALL follow the following rules :
>>> =20
>>> =20
>>> =20
>>>    For each candidate certificate, OCSP clients SHALL verify=20
>>> =20
>>>    whether there exists a locally defined rule for the certificate in=20
>>> =20
>>>    question which indicates the URI where the OCSP responder is=20
>>> =20
>>>    located.  If this rule exists, it SHALL be followed.=20
>>> =20
>>> =20
>>> =20
>>>    Otherwise, OCSP clients SHALL determine whether the candidate=20
>>> =20
>>>    certificate contains an AIA extension with an accessMethod which=20
>>> =20
>>>    contains the id-ad-ocsp OID.  If  it is the case, the accessLocation=
=20
>>> =20
>>>    contains a uniformResourceIdentifier (URI) which indicates the=20
>>> =20
>>>    location of the OCSP server for that certificate.=20
>>> =20
>>> =20
>>> =20
>>>    Certificates that contain the same URI MAY be grouped in a single=20
>>> =20
>>>    request.
>>> =20
>>> =20
>>> =20
>>> Note:  For each candidate certificate, when performing the path=20
>>> =20
>>>        validation  algorithm, the OCSP client SHOULD verify that the=20
>>> =20
>>>        current time is within the validity period of the target=20
>>> =20
>>>        certificate.  Certificates which are outside their validity=20
>>> =20
>>>        period SHOULD NOT be included in the request.
>>> =20
>>> =20
>>> =20
>>>    The requestor MAY choose to sign the OCSP request. In that case, the
>>> =20
>>>    signature is computed over the tbsRequest structure. If the request
>>> =20
>>>    is signed, the requestor SHALL specify its name in the requestorName
>>> =20
>>>    field. Also, for signed requests, the requestor MAY include
>>> =20
>>>    certificates that help the OCSP responder verify the requestor's
>>> =20
>>>    signature in the certs field of Signature.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>> =20
>> Your text may provide guidance that could be useful to some implementers=
, but=20
>> is completely beyond this document and further, not generally applicable=
 or=20
>> true.
>> =20
>> As an example, an organisation may setup an in house locally configured =
OCSP=20
>> responder that responds to all certificates "out there" that is relevant=
 to=20
>> that organisation.
>> =20
>> Such clients would just blindly send OCSP requests to their local respon=
der,=20
>> disregarding any information in the cert.
>> =20
>> It's totally beyond this spec to have an opinion about this.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 18. The text states on page 14:
>>> =20
>>> =20
>>> =20
>>>    The responder MAY include certificates in the
>>> =20
>>>    certs field of BasicOCSPResponse that help the OCSP client verify th=
e
>>> =20
>>>    responder's signature. If no certificates are included then certs
>>> =20
>>>    SHOULD be absent.
>>> =20
>>> =20
>>> =20
>>> While this sentence is true, it is not sufficient. In order to allow=20
>>> verifying every SingleResponse,=20
>>>  it is important to include the relevant certificates which are pertine=
nt to=20
>>> every SingleResponse.
>>> =20
>>> =20
>>> =20
>>> Proposed  full text replacement:
>>> =20
>>> =20
>>> =20
>>>    The responder MAY include certificates in the certs field of=20
>>> =20
>>>    BasicOCSPResponse  that help the OCSP client verify the responder's=20
>>> =20
>>>    signature.
>>> =20
>>> =20
>>> =20
>>>    For every SingleResponse where the responder is not a CA, the=20
>>> =20
>>>    responder SHALL include the relevant OCSP certificate in the certs=20
>>> =20
>>>    field of BasicOCSPResponse in order to allow the OCSP client=20
>>> =20
>>>    verifying the responder was entitled to include that SingleResponse=20
>>> =20
>>>    in the signed BasicOCSPResponse.
>>> =20
>>> =20
>>> =20
>>>    If no certificates are included then certs SHOULD be absent.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>> =20
>> This requirement would break backwards compatibility with RFC 2560.
>> =20
>> Further this would not be needed for a locally configured responder.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 19. Page 15. The ASN.1 syntax should be changed in order to be able to =
use=20
>>> the enumeration case 7 that is not used for CRLs.=20
>>>  This leads to the following change:
>>> =20
>>> =20
>>> =20
>>> Current text:
>>> =20
>>> =20
>>> =20
>>>        revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }
>>> =20
>>> =20
>>> =20
>>> Proposed  text change:
>>> =20
>>> =20
>>> =20
>>> Current text:
>>> =20
>>> =20
>>> =20
>>>        revocationReason    [0]     EXPLICIT RevocationReason OPTIONAL }
>>> =20
>>> =20
>>> =20
>>> RevocationReason ::=3D  ENUMERATED {
>>> =20
>>>         unspecified                    (0),
>>> =20
>>>         keyCompromise                  (1),
>>> =20
>>>         cACompromise                   (2),
>>> =20
>>>         affiliationChanged             (3),
>>> =20
>>>         superseded                     (4),
>>> =20
>>>         cessationOfOperation           (5),
>>> =20
>>>         certificateHold                (6),
>>> =20
>>>         notIssuedOrIrregularlyIssued    (7),
>>> =20
>>>         removeFromCRL                  (8),
>>> =20
>>>         privilegeWithdrawn             (9),
>>> =20
>>>         aACompromise                  (10) }
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>> =20
>> You have to convince the list about your new reason code.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 20. Page 15. After the ASN.1 syntax, there is no description of every=20
>>> parameter, neither on its use=20
>>>  (except a few words in section 4.2.2.1 Time about thisUpdate, nextUpda=
te=20
>>> and producedAt).
>>> =20
>>> =20
>>> =20
>>> Every parameter needs to be described and explained.
>>> =20
>>> =20
>>> =20
>>>    responderID indicates either the name or the key from a CA, or the=20
>>> =20
>>>    name or the key from a OCSP Responder.
>>> =20
>>> =20
>>> =20
>>>    producedAt indicates the time at which this response was signed.
>>> =20
>>> =20
>>> =20
>>>    responses contains one or more single responses.
>>> =20
>>> =20
>>> =20
>>>    responseExtensions is OPTIONAL.  Any  specific extension is OPTIONAL=
.
>>> =20
>>>    The critical flag may or may not be set.
>>> =20
>>> =20
>>> =20
>>>    certID is usually a copy of the same field which was placed in the=20
>>> =20
>>>    request, but for OCSP responders which pre-produce signed responses=20
>>> =20
>>>    certID may be the identifier of a target certificate that was not=20
>>> =20
>>>    present in the request (see the end of section 4.2).
>>> =20
>>> =20
>>> =20
>>>    certStatus indicates the status of the certificate: either good,=20
>>> =20
>>>    revoked or unknown.
>>> =20
>>> =20
>>> =20
>>>    thisUpdate indicates the time at which the status being indicated=20
>>> =20
>>>    is known to be correct.
>>> =20
>>> =20
>>> =20
>>>    nextUpdate indicates the time at or before which newer information=20
>>> =20
>>>    will be available about the status of the certificate.  If=20
>>> =20
>>>    nextUpdate is not set, the server is indicating that newer=20
>>> =20
>>>    revocation information is available all the time.=20
>>> =20
>>> =20
>>> =20
>>>    If nextUpdate is set, it often corresponds to the {thisUpdate,=20
>>> =20
>>>    nextUpdate} interval in CRLs.  Responses whose nextUpdate value is=20
>>> =20
>>>    earlier than the local UTC time value SHOULD be considered=20
>>> =20
>>>    unreliable.  Responses whose thisUpdate time is later than the local=
=20
>>> =20
>>>    UTC time SHOULD be considered unreliable.
>>> =20
>>> =20
>>> =20
>>>    singleExtensions is OPTIONAL.  Any  specific extension is OPTIONAL.
>>> =20
>>>    The critical flag SHOULD NOT be set for any of them.
>>> =20
>>> =20
>>> =20
>>>    revocationTime  indicates the time at which the certificate was=20
>>> =20
>>>    revoked.
>>> =20
>>> =20
>>> =20
>>>    revocationReason is OPTIONAL.  It  includes all the cases that are=20
>>> =20
>>>    present in CRLReason used for CRLs and an additional case 7 which is
>>> =20
>>>    not used for CRLs.  Case 7 is called notIssuedOrIrregularlyIssued.=20
>>> =20
>>> =20
>>> =20
>>>       - "notIssued" corresponds to the case where the certificate=20
>>> =20
>>>          serial number that was sent was erroneous and has not yet=20
>>> =20
>>>          been used by the CA at the time of the query,
>>> =20
>>> =20
>>> =20
>>>       - "irregularlyIssued" corresponds to the case where the=20
>>> =20
>>>          certificate  serial number that was sent really exists in a=20
>>> =20
>>>          certificate that is correctly signed, but to its knowledge=20
>>> =20
>>>          the CA has not issued a certificate with such a serial=20
>>> =20
>>>          number.  As an example, it may have been issued by the CA=20
>>> =20
>>>          because the RA was compromised.=20
>>> =20
>>> =20
>>> =20
>>>    When a responder responds revoked to a status request for which it=20
>>> =20
>>>    knows that the serial number has not been used by the CA or has=20
>>> =20
>>>    been irregularly used irregularly to issue a certificate, then=20
>>> =20
>>>    in RevokedInfo the responder MUST:
>>> =20
>>> =20
>>> =20
>>>       - specify the revocationTime :  January 1, 1970,
>>> =20
>>>       - provide the revocationReason: notIssuedOrIrregularlyIssued (7).
>>> =20
>>> =20
>>> =20
>>>    and in SingleResponse the responder MUST NOT include the nextUpdate.
>>> =20
>>> =20
>>> =20
>>>    The response MUST include a SingleResponse for each certificate in
>>> =20
>>>    the request and SHOULD NOT include any additional SingleResponse
>>> =20
>>>    elements.  However, there is one exception:=20
>>> =20
>>> =20
>>> =20
>>>       OCSP responders MAY pre-produce signed responses specifying the=20
>>> =20
>>>       status of certificates at a specified time.  The time at which=20
>>> =20
>>>       the status was known to be correct SHALL be reflected in the=20
>>> =20
>>>       thisUpdate field of the response.=20
>>> =20
>>> =20
>>> =20
>>>       OCSP responders that pre-generate status responses MAY return=20
>>> =20
>>>       responses that include additional SingleResponse elements if
>>> =20
>>>       necessary to improve response pre-generation performance or cache
>>> =20
>>>       efficiency (as permitted in [RFC5019]).
>>> =20
>>> =20
>>> =20
>>> Since the text above provides all the explanations at the level of the =
ASN.1=20
>>> parameters, the general text=20
>>>  from section 4.2.2.3 Basic Response is no more need and should be dele=
ted.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Preliminary I would say "not broken".
>> =20
>> If you don't replace 4.2.2.3, then what really are you missing?
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 21. 0n page 16, there is a section 4.2.2.2 called =B3Authorized Responder=
s=B2
>>> =20
>>> =20
>>> =20
>>> Section 4.2.2.2 states:
>>> =20
>>> =20
>>> =20
>>>    (=8A)
>>> =20
>>>    This certificate MUST be issued directly by the CA that issued the
>>> =20
>>>    certificate in question.
>>> =20
>>> =20
>>> =20
>>>    The CA SHOULD use the same issuing key to issue a delegation
>>> =20
>>>    certificate as was used to sign the certificate being checked for
>>> =20
>>>    revocation. Systems relying on OCSP responses MUST recognize a
>>> =20
>>>    delegation certificate as being issued by the CA that issued the
>>> =20
>>>    certificate in question only if the delegation certificate and the
>>> =20
>>>    certificate being checked for revocation was signed by the same key.
>>> =20
>>> =20
>>> =20
>>> This section would need to reformatted to address CA requirements first=
 and=20
>>> then OCSP responder requirements:
>>> =20
>>> =20
>>> =20
>>>    (=8A)
>>> =20
>>>    This certificate MUST be issued directly by the CA that issued the
>>> =20
>>>    certificate in question.  The CA SHOULD use the same issuing key to=20
>>> =20
>>>    issue a delegation certificate as was used to sign the certificate=20
>>> =20
>>>    being checked for revocation.=20
>>> =20
>>> =20
>>> =20
>>>    Systems relying on OCSP responses MUST be able to recognize a=20
>>> =20
>>>    delegation certificate as being issued by the CA that issued the=20
>>> =20
>>>    certificate in question if the delegation certificate and=20
>>> =20
>>>    the certificate being checked were signed by the same key.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> I disagree. The CA is actually free to do anything, but cannot expect th=
e=20
>> client to recognise the responder as authorised unless the same private =
key=20
>> is used.
>> =20
>> The current text places the requirement where they belong.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 22. On page 17, the text states:
>>> =20
>>> =20
>>> =20
>>>    They MUST reject the
>>> =20
>>>    response if the certificate required to validate the signature on th=
e
>>> =20
>>>    response fails to meet at least one of the following criteria:
>>> =20
>>> =20
>>> =20
>>> This is ambiguous. It is inappropriate to have a negative statement lik=
e=20
>>> =B3They MUST reject=B2.=20
>>>  The sentence should be turned in the positive form =B3They SHALL accept=B2=
=20
>>> =20
>>> =20
>>> =20
>>> Since the ASN.1 syntax has now be described, it is possible to be more=20
>>> specific.
>>> =20
>>> =20
>>> =20
>>> The first occurrence of the word =B3response=B2 should be changed into=20
>>> =B3singleResponse=B2, while the second occurrence=20
>>>  of the word =B3response=B2 should be changed into =B3ResponseData=B2
>>> =20
>>> =20
>>> =20
>>> Proposed  text replacement:
>>> =20
>>> =20
>>> =20
>>>    They SHALL accept a singleResponse if the certificate required to=20
>>> =20
>>>    validate the signature placed on the ResponseData meets one of the=20
>>> =20
>>>    following criteria:
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>>=20
>> =20
>> =20
>> No, this change is not backwards compatible.
>> =20
>> So state the requirements for rejection is not equivalent to stating=20
>> requirements for acceptance.
>> =20
>> There may be other locally configured reasons to reject in addition to t=
hose=20
>> listed in the standard.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 23. On page 17, the text states:
>>> =20
>>> =20
>>> =20
>>>    3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
>>> =20
>>>    extension and is issued by the CA that issued the certificate in
>>> =20
>>>    question as stated above."
>>> =20
>>> =20
>>> =20
>>> In order to be crystal clear, it is proposed to change the wording in t=
he=20
>>> following way:
>>> =20
>>> =20
>>> =20
>>>    3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
>>> =20
>>>    extension and was signed by the CA using the same key that used=20
>>> =20
>>>    to issue the certificate in question.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> No, issuing with another key is not prohibited, and may be accepted by s=
ome=20
>> clients as an authorised responder.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 24. On page 17, the text states:
>>> =20
>>> =20
>>> =20
>>>    This SHOULD be a non-critical extension. The value of the extension=20
>>> =20
>>>    SHALL be NULL.
>>> =20
>>> =20
>>> =20
>>> The ASN.1 syntax is missing. Add:=20
>>> =20
>>> =20
>>> =20
>>>    NoCheck ::=3D NULL
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Moving this to a separate discussion.
>> =20
>> I'm not sure what the preferred way to describe this is.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 25. Remainder: On page 18, the general text from section 4.2.2.3 Basic=20
>>> Response is no more needed and=20
>>>  should be deleted. See comment 20.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 26. On page 24, text should be added to the Security consideration sect=
ion:
>>> =20
>>> =20
>>> =20
>>> Different  results when using OCSP and CRLs
>>> =20
>>> =20
>>> =20
>>>    OCSP clients or verifiers must build and verify a certification path=
=20
>>> =20
>>>    for each target certificate up to a trusted root.  When an OCSP=20
>>> =20
>>>    Responder is using published CRLs, it must also build and verify a=20
>>> =20
>>>    certification path for the CRLs it uses up to a trusted root.
>>> =20
>>> =20
>>> =20
>>>    However, it should be realized that the root used by an OCSP=20
>>> =20
>>>    Responder to verified these CRLs is not necessarily the same as the=20
>>> =20
>>>    one that would be used by the OCSP client, if it were going to verif=
y=20
>>> =20
>>>    the CRLs itself.  Hence the revocation status may not be identical=20
>>> =20
>>>    in both cases.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> I don't understand this one.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 27. On page 24, text should be added to the Security consideration sect=
ion:
>>> =20
>>> =20
>>> =20
>>> Denial  of service attack using a flood of queries
>>> =20
>>> =20
>>> =20
>>>    A denial of service vulnerability is evident with respect to a flood=
=20
>>> =20
>>>    of queries.  The production of a cryptographic signature=20
>>> =20
>>>    significantly affects response generation cycle time, thereby=20
>>> =20
>>>    exacerbating the situation.=20
>>> =20
>>> =20
>>> =20
>>>    The flood of queries may either come from a flood attack or from the=
=20
>>> =20
>>>    fact that there are too many certificates supported by the same OCSP=
=20
>>> =20
>>>    responder.  In the later case, the number of queries can be=20
>>> =20
>>>    reduced by using a technique similar to the splitting of CRLs:=20
>>> =20
>>> =20
>>> =20
>>>       When a block of certificates have been issued with the same=20
>>> =20
>>>       accessLocation in the AIA extension field of these certificates,=20
>>> =20
>>>       then the accessLocation should be changed.  In this way, a given=20
>>> =20
>>>       OCSP server will only be responsible for a block of certificates.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> If the security considerations section is talking about splitting OCSP=20
>> responders in this way, then the document itself need to introduce the=20
>> subject.
>> =20
>> I would suggest that it is beyond this update to do so.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 28. On page 31, the text states.
>>> =20
>>> =20
>>> =20
>>>    An alternative to this module that conforms to the 2002 version of=20
>>> =20
>>>    ASN.1 may be found in Section 4 of [RFC5912].=20
>>> =20
>>> =20
>>> =20
>>> RFC 5912 omits to define the nocheck extension. Thus it is inappropriat=
e to=20
>>> refer to RFC 5912.=20
>>> =20
>>> =20
>>> =20
>>> The corrected module should be defined in this new draft.=20
>>>  A corrected module is provided in draft-pinkas-rfc2560bis-03.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Will move this (as stated above) to a separate discussion.
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> 29. Different topics are not covered by the document. These topics are=20
>>> important.=20
>>>  The following comments propose text to be placed in annexes. Three ann=
exes=20
>>> are being proposed.
>>> =20
>>> =20
>>> =20
>>> Note: The texts are extracted from draft-pinkas-rfc2560bis-03.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>> Each such amendment need to be thoroughly reviewed and motivated.
>> =20
>>=20
>> =20
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> 30. First annex being proposed. This annex is important, because key=20
>>> rollover is not addressed in the draft.
>>> =20
>>> =20
>>> =20
>>> KEY  ROLLOVER
>>> =20
>>> =20
>>> =20
>>> 1. CA that directly supports an OCSP service
>>> =20
>>> =20
>>> =20
>>>    When a CA that directly supports an OCSP service performs a key=20
>>> =20
>>>    rollover:
>>> =20
>>> =20
>>> =20
>>>    - for certificates issued under the old key, the CA SHALL continue=20
>>> =20
>>>      to sign the revocation status of OCSP responses with that old key=20
>>> =20
>>>      at least until all these certificates are expired, and
>>> =20
>>> =20
>>> =20
>>>    - for certificates issued under the new key, the CA SHALL change the=
=20
>>> =20
>>>      accessLocation in the AIA extension field of these certificates=20
>>> =20
>>>      and sign the revocation status of OCSP responses with that new key=
=20
>>> =20
>>>      at least until all these certificates are expired.
>>> =20
>>> =20
>>> =20
>>>    Note: The change in accessLocation is necessary when the CA rekeys=20
>>> =20
>>>          to meet the following constraints imposed by this standard:=20
>>> =20
>>> =20
>>> =20
>>>             1) a BasicOCSPResponse can only be signed using a single=20
>>> =20
>>>                private  key;=20
>>> =20
>>> =20
>>> =20
>>>             2) the response must be signed using the same CA key that=20
>>> =20
>>>                was used to sign the certificate in question; and
>>> =20
>>> =20
>>> =20
>>>             3) the OCSP response needs to cover all the certificates=20
>>> =20
>>>                queried in the OCSP request.
>>> =20
>>> =20
>>> =20
>>> 2. CA that uses OCSP responders
>>> =20
>>> =20
>>> =20
>>>    When a CA that uses OCSP Responders performs a key rollover, then=20
>>> =20
>>>    it MUST either designate a new OCSP Responder or keep the current=20
>>> =20
>>>    OCSP Responder(s).
>>> =20
>>> =20
>>> =20
>>>    If the CA designates a new OCSP Responder, then it SHALL change the=20
>>> =20
>>>    accessLocation in the AIA extension field for the newly issued=20
>>> =20
>>>    certificates and issue an OCSP certificate to the new OCSP Responder=
=20
>>> =20
>>>    using its new key.
>>> =20
>>> =20
>>> =20
>>>    If the CA keeps the same OCSP Responder(s), then it SHALL continue=20
>>> =20
>>>    to use the same accessLocation(s) in the AIA extension field for the=
=20
>>> =20
>>>    newly issued certificates and issue an OCSP certificate to the=20
>>> =20
>>>    appropriate OCSP Responder(s) using its new key.
>>> =20
>>> =20
>>> =20
>>>    Note: The CA may need to continue issuing certificates to the OCSP=20
>>> =20
>>>    Responder(s) using the old CA key until all the certificates issued=20
>>> =20
>>>    under the CA' old key for which the OCSP Responder(s) are=20
>>> =20
>>>    authoritative have expired.
>>> =20
>>> =20
>>> =20
>>> 3. OCSP Responder key rollover
>>> =20
>>> =20
>>> =20
>>>    When an OCSP Responder performs a key rollover (asynchronously from=20
>>> =20
>>>    a CA key rollover), then each CA which has designated an OCSP=20
>>> =20
>>>    Responder SHALL issue a new certificate for that OCSP Responder and=20
>>> =20
>>>    for each of its issuing keys which meets the following property:=20
>>> =20
>>> =20
>>> =20
>>>       - the issuing key has been used to sign at least one certificate=20
>>> =20
>>>         which contains an AIA extension designating that OCSP Responder=
=20
>>> =20
>>>         and that certificate is not yet expired.
>>> =20
>>> =20
>>> =20
>>>    An OCSP Responder key rollover does not affect the values of the=20
>>> =20
>>>    URIs that are placed in the accessLocation field from the target=20
>>> =20
>>>    certificates.  One or more OCSP Responder MAY respond to an OCSP=20
>>> =20
>>>    request addressed at a given URI picked from the accessLocation=20
>>> =20
>>>    field from a target certificate.  Each OCSP Responder MAY use a=20
>>> =20
>>>    different signing key, as long as it got an OCSP certificate=20
>>> =20
>>>    appropriate for that signing key and for the target certificate.=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 31. Second annex being proposed. This annex is important because it=20
>>> describes the validation of an OCSP response in the past=20
>>>  which is of a particular importance when validating electronic signatu=
res.
>>> =20
>>> =20
>>> =20
>>> Response  processing by an OCSP client
>>> =20
>>> =20
>>> =20
>>>    OCSP responses can be verified at the current time by an OCSP client=
=20
>>> =20
>>>    when receiving a response, whereas old responses can be verified at=20
>>> =20
>>>    a time in the past by a verifier.  The algorithm below addresses=20
>>> =20
>>>    both cases.
>>> =20
>>> =20
>>> =20
>>>    Prior to processing a basic response, OCSP clients MUST determine=20
>>> =20
>>>    the checking time, which may be either the current time or a time=20
>>> =20
>>>    in the past.
>>> =20
>>> =20
>>> =20
>>>    OCSP clients or verifiers SHALL check if the response contains=20
>>> =20
>>>    responseExtensions. If such an extension is found and is recognized,=
=20
>>> =20
>>>    it MUST be processed.  If such a critical extension is found and=20
>>> =20
>>>    is not recognized, the whole OCSP response MUST be considered as=20
>>> =20
>>>    invalid.
>>> =20
>>> =20
>>> =20
>>>    If the checking time is the current time, and if a nonce extension=20
>>> =20
>>>    has been used in the request and is recognized (see section 4.5.1),=20
>>> =20
>>>    OCSP clients MUST check whether the same nonce is present in the=20
>>> =20
>>>    response.  If the nonce is not present or is different, then the=20
>>> =20
>>>    OCSP response MUST be discarded.
>>> =20
>>> =20
>>> =20
>>>    Only the single response(s) which are/is of interest SHALL be=20
>>> =20
>>>    checked.
>>> =20
>>> =20
>>> =20
>>> STEP  1
>>> =20
>>> =20
>>> =20
>>>    OCSP clients or verifiers SHALL verify that the certificate=20
>>> =20
>>>    identified in a single response is of interest.  Otherwise, proceed=20
>>> =20
>>>    to step 3.
>>> =20
>>> =20
>>> =20
>>>    If the certificate status included in a single certificate response=20
>>> =20
>>>    is "unknown", then the revocation status of that certificate is=20
>>> =20
>>>    "unknown", and proceed to step 3.
>>> =20
>>> =20
>>> =20
>>>    If the certificate status from the single certificate response is=20
>>> =20
>>>    either "good" or "revoked", OCSP clients or verifiers SHALL check=20
>>> =20
>>>    that the checking time is within the validity period of the target=20
>>> =20
>>>    certificate.  If it is not the case, then the revocation status of=20
>>> =20
>>>    that certificate is "unknown" and proceed to step 3.
>>> =20
>>> =20
>>> =20
>>>    If the checking time is the current time, and if a nonce has been=20
>>> =20
>>>    used in the request, then proceed to step 2.
>>> =20
>>> =20
>>> =20
>>>    If the checking time is the current time, and if no nonce has been=20
>>> =20
>>>    used in the request, OCSP clients MUST check that the producedAt
>>> =20
>>>    field is within a time window that is "close enough" to the current=20
>>> =20
>>>    time.=20
>>> =20
>>> =20
>>> =20
>>>    Note: the notion of "close enough" is a local matter.  It can be set=
=20
>>> =20
>>>          to a few minutes to allow for small UTC time differences=20
>>> =20
>>>          between the client and the server or to a few hours in case=20
>>> =20
>>>          the server is producing pre-computed responses.
>>> =20
>>> =20
>>> =20
>>>    If the checking time is a time in the past, verifiers MUST check=20
>>> =20
>>>    that the producedAt field is in accordance with the verification=20
>>> =20
>>>    rules (e.g. close and/or after the date of a time-stamp token).
>>> =20
>>> =20
>>> =20
>>>    In addition, if the nextUpdate field is present, OCSP clients MUST=20
>>> =20
>>>    check that the time which is indicated is greater than the checking=20
>>> =20
>>>    time, otherwise the single response MUST be discarded.
>>> =20
>>> =20
>>> =20
>>>    If checks are successful, then OCSP clients MUST process the=20
>>> =20
>>>    singleExtensions  field, if it is present.=20
>>> =20
>>> =20
>>> =20
>>>    If the criticality flag is set and the extension is not understood,=20
>>> =20
>>>    then the status of the certificate shall be "unknown" and proceed to=
=20
>>> =20
>>>    step 3.  Otherwise, proceed to step 2.=20
>>> =20
>>> =20
>>> =20
>>>    If the extension is understood, then the extension MUST be=20
>>> =20
>>>    processed.  According to its content proceed either to step 2 or to=20
>>> =20
>>>    step 3.=20
>>> =20
>>> =20
>>> =20
>>> STEP  2
>>> =20
>>> =20
>>> =20
>>>    OCSP clients or verifiers MUST build and verify a certification path=
=20
>>> =20
>>>    for that certificate up to a trusted root, so that they have the=20
>>> =20
>>>    knowledge of the CA public key value that was used to sign the=20
>>> =20
>>>    target certificate.  The revocation status of each certificate of=20
>>> =20
>>>    that certification path (except the target certificate) SHALL be=20
>>> =20
>>>    checked.
>>> =20
>>> =20
>>> =20
>>>    If no path can be built or if one of the certificates of the path is=
=20
>>> =20
>>>    revoked, then the revocation status of that certificate is "unknown"=
,=20
>>> =20
>>>    and proceed to step 3.=20
>>> =20
>>> =20
>>> =20
>>>    If the certification path (except the target certificate) is valid,=20
>>> =20
>>>    then two cases need to be considered:
>>> =20
>>> =20
>>> =20
>>>    a) If the responderID matches with the name or the key from the CA=20
>>> =20
>>>       which has issued the target certificate, then check whether the=20
>>> =20
>>>       OCSP response is signed by the same key that was used to sign=20
>>> =20
>>>       the target certificate.
>>> =20
>>> =20
>>> =20
>>>              If it is the case, then the revocation status of that=20
>>> =20
>>>              certificate  as indicated in the certStatus field is=20
>>> =20
>>>              accepted and proceed to step 3.
>>> =20
>>> =20
>>> =20
>>>              If it is not the case, then the revocation status of that=20
>>> =20
>>>              certificate  is "unknown" and proceed to step 3.
>>> =20
>>> =20
>>> =20
>>>    b) If the responderID does not match with the name or the key from=20
>>> =20
>>>       the CA which has issued the target certificate, then it indicates=
=20
>>> =20
>>>       the name or the key from an OCSP Responder.  Check whether there=20
>>> =20
>>>       exists a local rule which applies to this target certificate to=20
>>> =20
>>>       verify that the signature of the BasicOCSPResponse is valid for=20
>>> =20
>>>       that single response.  If this rule exists, it SHALL be followed.=
=20
>>> =20
>>> =20
>>> =20
>>>       Otherwise check whether there is an OCSP certificate (i.e. which=20
>>> =20
>>>       has both the ocspSigning OID in the extended key usage extension=20
>>> =20
>>>       and the digitalSignature bit in the key usage extension) signed=20
>>> =20
>>>       by the same key that was used to sign the target certificate.=20
>>> =20
>>>       This certificate MUST be present in the certs field from the=20
>>> =20
>>>       BasicOCSPResponse. =20
>>> =20
>>> =20
>>> =20
>>>           If such certificate is not found or is invalid, then the=20
>>> =20
>>>           revocation  status of that certificate is "unknown" and=20
>>> =20
>>>           proceed to step 3.
>>> =20
>>> =20
>>> =20
>>>           If such certificate exists and if the checking time is=20
>>> =20
>>>           within the validity period of this certificate, then it MUST=20
>>> =20
>>>           be verified whether the OCSP response can be verified using=20
>>> =20
>>>           the public key that is present in the OCSP Certificate.=20
>>> =20
>>> =20
>>> =20
>>>              If it is not the case, then the revocation status of that=20
>>> =20
>>>              certificate  is "unknown" and proceed to step 3.
>>> =20
>>> =20
>>> =20
>>>              If it is the case, then it MUST be verified that the OCSP=20
>>> =20
>>>              Certificate  has not been revoked.
>>> =20
>>> =20
>>> =20
>>>      If one of these conditions is met, then the status for the target=20
>>> =20
>>>      certificate as indicated in the certStatus field is accepted,=20
>>> =20
>>>      otherwise the revocation status is "unknown".
>>> =20
>>> =20
>>> =20
>>> STEP  3
>>> =20
>>> =20
>>> =20
>>>    If there exists another single certificate status response for a=20
>>> =20
>>>    target certificate that is of interest, then proceed to step 1.=20
>>> =20
>>>    Otherwise the basic response is now processed.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 32. Third annex being proposed. This annex is important because it prov=
ides=20
>>> guidance on how to build an OCSP responder in the three cases.=20
>>>  Many text portions are similar, but three full texts are provided in o=
rder=20
>>> to provide a better clarity for each of the three cases.
>>> =20
>>> =20
>>> =20
>>> 1. Request processing by OCSP servers
>>> =20
>>> =20
>>> =20
>>>    The behavior of an OCSP server will be different whether the OCSP=20
>>> =20
>>>    server is a CA acting as an OCSP responder, is an OCSP Responder=20
>>> =20
>>>    which received a delegation from one or more CAs, or is a locally=20
>>> =20
>>>    trusted Responder.
>>> =20
>>> =20
>>> =20
>>> 1.1.  Processing by a CA acting as an OCSP responder
>>> =20
>>> =20
>>> =20
>>>    The OCSP responder SHALL maintain a list of entries. Each entry=20
>>> =20
>>>    SHALL contain:
>>> =20
>>> =20
>>> =20
>>>      - the URI associated to the OCSP responder, from which the OCSP=20
>>> =20
>>>        requests are received,=20
>>> =20
>>> =20
>>> =20
>>>      - the DN from a CA,
>>> =20
>>> =20
>>> =20
>>>      - an issuing public key from a CA,
>>> =20
>>> =20
>>> =20
>>>      - the method(s) used to know for which subset of certificates=20
>>> =20
>>>        issued by the CA it is responsible for,=20
>>> =20
>>> =20
>>> =20
>>>      - the method(s) used to obtain the revocation status of that=20
>>> =20
>>>        subset of certificates issued under that CA issuing public key,=20
>>> =20
>>>        and
>>> =20
>>> =20
>>> =20
>>>      - the method used to gain access and sign with the private key=20
>>> =20
>>>        corresponding to the issuing public key.
>>> =20
>>> =20
>>> =20
>>>    For a given URI value, the OCSP responder SHALL only use one CA=20
>>> =20
>>>    key pair value.=20
>>> =20
>>> =20
>>> =20
>>>    When it receives an OCSP request on that URI, the OCSP responder=20
>>> =20
>>>    SHALL handle exceptions according to section 2.3.=20
>>> =20
>>> =20
>>> =20
>>>    If the OCSP request contains the name of a requestor, the OCSP=20
>>> =20
>>>    responder SHALL verify whether there exists a locally defined rule=20
>>> =20
>>>    which regulates access control.  If this rule exists, it SHALL be=20
>>> =20
>>>    followed.
>>> =20
>>> =20
>>> =20
>>>    Then, for each target certificate, the OCSP responder SHALL verify=20
>>> =20
>>>    whether both the hash of the issuer's DN and the hash of the issuer=20
>>> =20
>>>    public key which are present in the request are eligible to a=20
>>> =20
>>>    locally defined rule which indicates that the OCSP responder is=20
>>> =20
>>>    responsible to provide the revocation status of that target=20
>>> =20
>>>    certificate.  If this rule exists, it SHALL be followed.
>>> =20
>>> =20
>>> =20
>>>    Otherwise, the OCSP responder SHALL determine whether it is=20
>>> =20
>>>    responsible to provide the revocation status of that target=20
>>> =20
>>>    certificate according to the following rule.
>>> =20
>>> =20
>>> =20
>>>    For each target certificate, the OCSP responder SHALL verify whether=
=20
>>> =20
>>>    both the hash of the issuer's DN and the hash of the issuer public=20
>>> =20
>>>    key which are present in the request match respectively with the DN=20
>>> =20
>>>    and the hash of the public key of contained in an entry from the=20
>>> =20
>>>    list of entries maintained by this OCSP responder.=20
>>> =20
>>> =20
>>> =20
>>>    When there is no match, then the OCSP responder SHALL indicate the=20
>>> =20
>>>    "unknown" status and proceed with the next target certificate from=20
>>> =20
>>>    the OCSP request.
>>> =20
>>> =20
>>> =20
>>>    When there is a match, then the OCSP responder SHALL use the serial=20
>>> =20
>>>    number of the target certificate that is present in the request and=20
>>> =20
>>>    determine the revocation status of that certificate according to=20
>>> =20
>>>    the method(s) defined in the entry.=20
>>> =20
>>> =20
>>> =20
>>>    When the revocation status is provided by the server using a real=20
>>> =20
>>>    time access to a database of revocation statuses of issued=20
>>> =20
>>>    certificates, then the thisUpdate field SHALL be present in the
>>> =20
>>>    SingleResponse  response whereas the nextUpdate field SHALL be=20
>>> =20
>>>    missing.=20
>>> =20
>>> =20
>>> =20
>>>    Otherwise, both the thisUpdate and the nextUpdate fields SHALL be=20
>>> =20
>>>    present in the SingleResponse.=20
>>> =20
>>> =20
>>> =20
>>>    The time at which this response will be signed MUST be indicated in=20
>>> =20
>>>    the producedAt field from the SingleResponse.
>>> =20
>>> =20
>>> =20
>>>    If a singleRequestExtensions is present in the request it MUST be=20
>>> =20
>>>    processed.
>>> =20
>>> =20
>>> =20
>>>    If there is another target certificate present in the request, it=20
>>> =20
>>>    SHALL be processed in the same way.
>>> =20
>>> =20
>>> =20
>>>    If a requestExtensions is present in the request it MUST be=20
>>> =20
>>>    processed.
>>> =20
>>> =20
>>> =20
>>>    The OCSP response MUST be signed using the CA issuing private key.
>>> =20
>>> =20
>>> =20
>>> =20
>>> =20
>>> 1.2.  Processing by an OCSP Responder
>>> =20
>>> =20
>>> =20
>>>    For each CA from which the OCSP Responder has received a delegation,=
=20
>>> =20
>>>    the OCSP Responder SHALL maintain a list of entries.=20
>>> =20
>>> =20
>>> =20
>>>    Each entry SHALL contain:
>>> =20
>>> =20
>>> =20
>>>      - the URI associated to this OCSP Responder, from which the OCSP=20
>>> =20
>>>        requests are received,=20
>>> =20
>>> =20
>>> =20
>>>      - the DN from a CA,
>>> =20
>>> =20
>>> =20
>>>      - an issuing public key from a CA,
>>> =20
>>> =20
>>> =20
>>>      - the method(s) used to know for which subset of certificates=20
>>> =20
>>>        issued by the CA it is responsible for,=20
>>> =20
>>> =20
>>> =20
>>>      - the method(s) used to obtain the revocation status of that=20
>>> =20
>>>        subset of certificates issued under that CA issuing public key,
>>> =20
>>> =20
>>> =20
>>>      - an OCSP certificate,=20
>>> =20
>>> =20
>>> =20
>>>      - the OCSP public key contained in that OCSP certificate, and
>>> =20
>>> =20
>>> =20
>>>      - the method used to gain access and sign with the OCSP private=20
>>> =20
>>>        key corresponding to that OCSP certificate.
>>> =20
>>> =20
>>> =20
>>>    For a given URI value, the OCSP Responder SHALL only use one OCSP=20
>>> =20
>>>    key pair value.  Therefore there cannot be two entries with the=20
>>> =20
>>>    same URI value and a different OCSP public key value.
>>> =20
>>> =20
>>> =20
>>>    NOTE: a BasicOCSPResponse can only be signed using a single private=20
>>> =20
>>>          key.=20
>>> =20
>>> =20
>>> =20
>>>    The OCSP certificate SHALL be signed by the CA issuing private key=20
>>> =20
>>>    which corresponds to the issuing CA public key that is in this=20
>>> =20
>>>    entry.
>>> =20
>>> =20
>>> =20
>>>    When it receives an OCSP request, the OCSP responder SHALL handle=20
>>> =20
>>>    exceptions according to section 2.3.=20
>>> =20
>>> =20
>>> =20
>>>    If the OCSP request contains the name of a requestor, the OCSP=20
>>> =20
>>>    responder SHALL verify whether there exists a locally defined rule=20
>>> =20
>>>    which regulates access control.  If this rule exists, it SHALL be=20
>>> =20
>>>    followed.
>>> =20
>>> =20
>>> =20
>>>    For each target certificate, the OCSP Responder SHALL verify=20
>>> =20
>>>    whether both the hash of the issuer's DN and the hash of the issuer=20
>>> =20
>>>    public key which are present in the OCSP request match with those=20
>>> =20
>>>    from an entry.
>>> =20
>>> =20
>>> =20
>>>    When there is no match, then the OCSP Responder SHALL indicate the=20
>>> =20
>>>    "unknown" status and proceed with the next target certificate from=20
>>> =20
>>>    the OCSP request.
>>> =20
>>> =20
>>> =20
>>>    When there is a match, the OCSP Responder SHALL use the serial=20
>>> =20
>>>    number of the target certificate this is present in the OCSP=20
>>> =20
>>>    request to determine the revocation status of that certificate=20
>>> =20
>>>    according to the method(s) indicated in the entry.=20
>>> =20
>>> =20
>>> =20
>>>    When the revocation status is provided by the server using a real=20
>>> =20
>>>    time access to a database of revocation statuses of issued=20
>>> =20
>>>    certificates, then the thisUpdate field SHALL be present in the
>>> =20
>>>    SingleResponse  response whereas the nextUpdate field SHALL be=20
>>> =20
>>>    missing.=20
>>> =20
>>> =20
>>> =20
>>>    Otherwise, both the thisUpdate and the nextUpdate fields SHALL be=20
>>> =20
>>>    present in the SingleResponse.=20
>>> =20
>>> =20
>>> =20
>>>    The time at which this response will be signed MUST be indicated in=20
>>> =20
>>>    the producedAt field from the SingleResponse.
>>> =20
>>> =20
>>> =20
>>>    If a singleRequestExtensions is present in the request it MUST be=20
>>> =20
>>>    processed.
>>> =20
>>> =20
>>> =20
>>>    If there is another target certificate present in the request, it=20
>>> =20
>>>    SHALL be processed in the same way.
>>> =20
>>> =20
>>> =20
>>>    If a requestExtensions is present in the request it SHALL be=20
>>> =20
>>>    processed.
>>> =20
>>> =20
>>> =20
>>>    The OCSP response MUST be signed using the OCSP private key.
>>> =20
>>> =20
>>> =20
>>>    Unless there is a local rule which states differently, for every=20
>>> =20
>>>    target certificate which matches both with the hash of a CA DN and a=
n=20
>>> =20
>>>    issuing public key from an entry, the OCSP certificate of that entry=
=20
>>> =20
>>>    SHALL be placed in the certs field.
>>> =20
>>> =20
>>> =20
>>>    It may happen, that none of the target certificates from the OCSP
>>> =20
>>>    request matches both with the hash of a CA DN and an issuing public=20
>>> =20
>>>    key from an entry.  In that case and unless a local rule states=20
>>> =20
>>>    differently, the certs field from the BasicOCSPResponse SHOULD be=20
>>> =20
>>>    kept empty (to limit the disclose of the names of the CAs from which=
=20
>>> =20
>>>    the OCSP Responder received a delegation from).
>>> =20
>>> =20
>>> =20
>>> 1.3.  Processing by a locally trusted Responder
>>> =20
>>> =20
>>> =20
>>>    For each CA for which the locally trusted Responder is=20
>>> =20
>>>    authoritative, the OCSP Responder SHALL maintain a list of entries.=20
>>> =20
>>> =20
>>> =20
>>>    Each entry SHALL contain:
>>> =20
>>> =20
>>> =20
>>>      - the URI associated to this OCSP Responder, from which the OCSP=20
>>> =20
>>>        requests are received,=20
>>> =20
>>> =20
>>> =20
>>>      - the DN from a CA,
>>> =20
>>> =20
>>> =20
>>>      - an issuing public key from a CA,
>>> =20
>>> =20
>>> =20
>>>      - the method(s) used to know for which subset of certificates=20
>>> =20
>>>        issued by the CA it is responsible for,=20
>>> =20
>>> =20
>>> =20
>>>      - the method(s) used to obtain the revocation status of that=20
>>> =20
>>>        subset of certificates issued under that CA issuing public key,
>>> =20
>>> =20
>>> =20
>>>      - the method used to gain access to the private key in order to=20
>>> =20
>>>        sign the OCSP response.=20
>>> =20
>>> =20
>>> =20
>>>    For a given URI value, the OCSP Responder SHALL only use one private=
=20
>>> =20
>>>    key.  Therefore there cannot be two entries with the same URI value=20
>>> =20
>>>    and a different method to gain access to the appropriate private key=
.
>>> =20
>>> =20
>>> =20
>>>    NOTE: a BasicOCSPResponse can only be signed using a single private=20
>>> =20
>>>          key.=20
>>> =20
>>> =20
>>> =20
>>>    When it receives an OCSP request, the OCSP responder SHALL handle=20
>>> =20
>>>    exceptions according to section 2.3.=20
>>> =20
>>> =20
>>> =20
>>>    If the OCSP request contains the name of a requestor, the OCSP=20
>>> =20
>>>    responder SHALL verify whether there exists a locally defined rule=20
>>> =20
>>>    which regulates access control.  If this rule exists, it SHALL be=20
>>> =20
>>>    followed.
>>> =20
>>> =20
>>> =20
>>>    For each target certificate, the OCSP Responder SHALL verify=20
>>> =20
>>>    whether both the hash of the issuer's DN and the hash of the issuer=20
>>> =20
>>>    public key which are present in the OCSP request match with those=20
>>> =20
>>>    from an entry.
>>> =20
>>> =20
>>> =20
>>>    When there is no match, then the OCSP Responder SHALL indicate the=20
>>> =20
>>>    "unknown" status and proceed with the next target certificate from=20
>>> =20
>>>    the OCSP request.
>>> =20
>>> =20
>>> =20
>>>    When there is a match, the OCSP Responder SHALL use the serial=20
>>> =20
>>>    number of the target certificate this is present in the OCSP=20
>>> =20
>>>    request to determine the revocation status of that certificate=20
>>> =20
>>>    according to the method(s) indicated in the entry.=20
>>> =20
>>> =20
>>> =20
>>>    When the revocation status is provided by the server using a real=20
>>> =20
>>>    time access to a database of revocation statuses of issued=20
>>> =20
>>>    certificates, then the thisUpdate field SHALL be present in the
>>> =20
>>>    SingleResponse  response whereas the nextUpdate field SHALL be=20
>>> =20
>>>    missing.=20
>>> =20
>>> =20
>>> =20
>>>    Otherwise, both the thisUpdate and the nextUpdate fields SHALL be=20
>>> =20
>>>    present in the SingleResponse.=20
>>> =20
>>> =20
>>> =20
>>>    The time at which this response will be signed MUST be indicated in=20
>>> =20
>>>    the producedAt field from the SingleResponse.
>>> =20
>>> =20
>>> =20
>>>    If a singleRequestExtensions is present in the request it MUST be=20
>>> =20
>>>    processed.
>>> =20
>>> =20
>>> =20
>>>    If there is another target certificate present in the request, it=20
>>> =20
>>>    SHALL be processed in the same way.
>>> =20
>>> =20
>>> =20
>>>    If a requestExtensions is present in the request it SHALL be=20
>>> =20
>>>    processed.
>>> =20
>>> =20
>>> =20
>>>    The OCSP response MUST be signed using the OCSP private key.
>>> =20
>>> =20
>>> =20
>>>    The certs field may contain no, one or several OCSP certificates=20
>>> =20
>>>    according to local rules followed by the locally trusted Responder.
>>> =20
>>> =20
>>> =20
>>  =20
>>=20
>> =20
>> =20
>> Not broken.
>> =20
>>=20
>> =20
>> =20
>> /Stefan
>> =20
>>=20
>> =20
>>  =20
>>> =20
>>> =20
>>> =20
>>>=20
>>> =20
>>> =20
>>> =20
>>> =20
>>> End of comments
>>> =20
>>> =20
>>>=20
>>>  Denis
>>> =20
>>> =20
>>> =20
>>>  =20
>>> =20
>>>  _______________________________________________ pkix mailing list=20
>>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix=20
>>  =20
> =20
> =20



--B_3444861647_28902524
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


Denis,

<=
div>My replies in line;

=

From=
:  Denis Pinkas <denis.pink=
as@bull.net>
Date:  Monday, =
February 11, 2013 3:18 PM
To:  Stef=
an Santesson <stefan@aaa-sec.com&=
gt;
Cc:  Stephen Kent <kent@bbn.com>, pkix <pkix@ietf.org>
Subject:  Re: [pkix] Review of 2560-bis draft 8. Answer to WGLC

=


  
    
  
  

    

        
        
Stefan,

        
 

        
I have
            finally reviewed your disposition of comments. I have used
            draft 13.

        
 

        
I will
            not <=
span style=3D"mso-ansi-language:EN-GB" lang=3D"EN-GB">address the comments in sequence, but
            I will consider four categories:

        
 

        
Category 1) Some comments which
            seem to be solved. Yes indeed, they may be a
            few of them !

        
 

        
Category 2) Some comments which
            might possibly be solved at the WG level.
=

        
 

        
Category 3) Some comments that
            I will address at the IETF last call
            level, rather than the WG last call level, since I disagree
            

            that it is “new
            ways to say the same thing” and it is likely to be a wast=
e
            of time for both of
            us to argue again at the WG level 

            (these comments are commented as “not
            broken”).

        
 

        
Category 4) Some typos and
            editorials found while reading
            draft 13.

        
 

        
 

        
CATEGORY 1=


        
 

        
Comment 4 (was
            editorial).

        
 

        
Comment 5.=


        
 
=

        
Comment 6. 

        
 

        
Comment 19. Solved, since
          “unknown” seems now to be also allowed for
            non-issued certificates 

            (even if the
            OCSP responder is using a direct access to the certificate
            database). See
            comment 8.

        
 

        
Comment 13: Acceptable,
            since the text uses “MAY=
221;.

        
 

        
Comment 18. 

        
 

        
Comment 22.

        
 

        
Comment 23.

        
 

        
Comment 28.

        
 

        
CATEGORY 1=


        
 

        
Comment 8: You have
            changed the meaning of the revoked
            state in a way that is not what I requested. =


        
 

        
The
            original text was:

        
 

        
   The
              "revoked" state indicates that the certificate has been
              revoked

        
  
              (either permanantly or temporarily (on hold)).

        
 

        
The new
            text is:

        
 
=

        
   The =
"revoked" state indicates that the certificate has been revoked

        
   eith=
er permanently or temporarily on hold (i.e. the revocation reason=


        
   is c=
ertificateHold).

        
 

        
By doing
            this, you do not allow any other case in the future to have
            a temporary
            revocation: “temporarily
on
              hold”=
 

            is not the same as “temporarily
              revoked”.

        
 

        
I propose
            the following rewording: 

        
 

        
   The
              "revoked" state indicates that the certificate has been
              revoked 

        
   eith=
er permanently or temporarily (e.g. placed on hold).
        

I substituted "temporarily on hold" with "temporarily. The rest unchanged =
since the only existing reason code for temporary revocation is certificateH=
old.


<=
br>

        
The way the
            text from draft 13 is now written seems to allow using
            either “unknow=
n” or “revoked” for non-issued certificates. 

            If this is the intent, then the good news
            is that this does not come anymore into conflict with the
            French rules which
            apply for 

            the Administration since OCSP responders from CAs used by
            the French
            Ministries having a direct access to the database 

            of issued certificates will
            be able to use “unknow=
n”, rath=
er than
          “revoke=
d” and t=
he reason
            code “onhold=
”.<=
/o:p>

        
 

        
However,
            the current text is still mandating the use of Extended Revoked
              Definition, but the rational for its need it
            is very poor. 

            As I have said on the PKIX list, the fact that the
            revocation
            date is January 1rst, 1970 is fully sufficient to know that
            we are in that 

            very
            special case, and you have not provided a rational to say
            the contrary.

        

I have. And I have pointed you to the minutes of the last PKIC meeting.
The consensus of the WG is to have the extension for just those reas=
ons.

As implementer, I don't like heuristics. A dat=
e of Jan 1st 1970 may indicate this behaviour, but may just be a misconfigur=
ation. It is not an explicit statement.

&=
nbsp;

        
So we could
            get rid of it, … but the text from section 4.4.8 states:<=
o:p>

        
 

        
   This=
 extension MAY be present in other responses to signal that the

        
   resp=
onder implements the extended revoked definition in section 2.2.<=
/span>

        
 

        
I have
            difficulties to understand what is really meant there
            (“other responses” ?),
            since the text states:

        
 

        
   This=
 extension indicates that the responder supports the extended

        
   defi=
nition of the "revoked" status to also include non-issued<=
/b>

        
   cert=
ificates according to section 2.2.

        
 

        
Since both
            “unknown” and revoked” can be used, it would =
be desirable to
            be able to include
            the same extension in both cases, 

            but in that case that extension should be
            renamed.

        

This extension can be included in all responses to signal that a responder=
 implements the expanded definition of revoked.
Doing so makes thi=
s fact auditable without having to ask for a non-issued cert.

=

=



        
I would
            propose to rename it: "non-issued certificate” which means that the associated CA =
has
            no record of ever having issued
            

            a certificate with the certificate serial number in the
            request (I still
            consider it as unnecessary in the case of “revoked”=
, but it
            would be 

            very
            useful in the case of “unknown”). Of course, the te=
xt from
            section 4.4.8 would
            need to be revised.

        
 

        
I propose
            the following:

        
 

        
4.4.8  Non-i=
ssued certificate extension

        
 

        
   This extension MUST be included in the OC=
SP response when the OCSP 

        
   responder knows that the CA identified in the request has no record 

        
   of ever having issued a certificate with the certificate serial =


        
   number indicated in the request.

        
 

        
   Clients do not have to parse this extensi=
on in order to determine 

        
   the status of certificates in responses.

        
 

        
   This extension is identified by the objec=
t identifier id-pkix-ocsp-

        
   non-=
issued-cert.

        
 

        
     id-pkix-ocsp-non-issued-cert =
OBJECT IDENTIFIER ::=3D {id-pkix-ocsp 9}

        
 

        
   The value of the extension SHALL be NULL.=
 This extension MUST NOT be

        
   mark=
ed critical.

        
 

        
Then the
            text on page 8 would need to be rearranged.
        
 
<=
/span>

Your extension  variant is a significant chan=
ge to what has been agreed.
Your extension would need to be a sing=
le response extension, and can't be used to audit the behaviour of the OCSP =
responder unless you send a request for a non-issued cert.
We want=
 to avoid sending such fake requests for audit purposes as it may interfere =
with systems at the responder trying to detect existence of rouge certificat=
es.

This is a type of change that I can't make unle=
ss you get support from a majority of the WG for the change of direction you=
 propose.


        
The current
            text is:

        
 

        
   This=
 state MAY also be returned if the

        
   asso=
ciated CA has no record of ever having issued a certificate with<=
/span>

        
   the =
certificate serial number in the request, using any current or

        
   prev=
ious issuing key (referred to as a "non-issued" certificate in

        
   this=
 document).

        
 

        
   The "unknown" state indicates that the re=
sponder doesn't know about

        
   the =
certificate being requested.

        
 

        
   NOTE: The "revoked" state for known non-i=
ssued certificate serial

        
    =
     numbers is allowed in order to reduce the ri=
sk of relying

        
    =
     parties using CRLs as a fall back mechanism,=
 which would be

        
    =
     considerably higher if an "unknown" response=
 was returned.

        
 

        
   When a responder responds revoked to a st=
atus request for a non-

        
   issu=
ed certificate, the responder MUST include the extended revoked

        
   defi=
nition response extension (section 4.4.8) in the response,=


        
   indi=
cating that the OCSP responder supports the extended definition

        
   of r=
evoked state to also cover non-issued certificates. In addition,<=
/span>

        
   the =
SingleResponse related to this non-issued certificate;=


        
 

        
    - MUST provide the revocation reaso=
n certificateHold (6),

        
 

        
    - MUST specify the revocationTime J=
anuary 1, 1970, and;

        
 

        
    - MUST NOT include a CRL References extension (section 4.4.2) or any=


        
    =
  CRL Entry Extensions (section 4.4.5). 
        
 

        
Proposed
            text for a replacement:

        
 

        
   The =
"unknown" state indicates that the responder doesn't know about

        
   the =
certificate being requested.

        
 

        
   If the OCSP responder knows that CA ident=
ified in the request has 

        
   no record of ever having issued a certificate with the certificate 

        
   serial number in the request, using any current or previous issuing 

        
   key (referred to as a "non-issued" certificate in this document), 

        
   the OCSP responder SHALL respond either “revoked “ or “un=
known”.

        

This is unfortunately very common in your rewording efforts. When trying t=
o fix one thing, you create new even bigger problems.

An infrastructure that provides reproduced responses will respond "unauth=
orized". This text may be interpreted to interfere with such operations.
Further, and worse. This is not backwards compatible. Current OCSP re=
sponders may respond "good" even if they have access to CA records. 

=
 

        
   Note: The "revoked" state for known non-i=
ssued certificate serial 

        
   numbers is allowed in order to reduce the risk of relying parties 

        
   using CRLs as a fall back mechanism, which would be possible when 

        
   the "unknown" response is returned.

        
 

        
   When a responder responds revoked or unkn=
own to a status request 

        
   for a non-issued certificate, the responder MUST include the 

        
   non-issued certificate extension (see section 4.4.8) in the 

        
   response. 

        
 

        
   When a responder responds revoked to a st=
atus request for a non-

        
   issu=
ed certificate, in addition, the responder:

        
 

        
    - MUST provide the revocation reaso=
n certificateHold (6),

        
 

        
    - MUST specify the revocationTime J=
anuary 1, 1970, and;

        
 

        
    - MUST NOT include a CRL References=
 extension (section 4.4.2) or any

        
    =
  CRL Entry Extensions (section 4.4.5).
        
 

        
Finally,
            the last bullet on page 4 should be reworded:=


        
 

        
Current
            text:

        
 

        
    =
  o Section 4.4.8 specifies a new extension that indicates that =
the

        
    =
     responder supports the extended use of the "=
revoked" response

        
    =
     for non-issued certificates defined in secti=
on 2.2.

        
 
=

        
Proposed
            replacement text:

        
 

        
    =
  o  Section 4.4.8 sp=
ecifies a new extension that indicates that 

        
    =
     the OCSP responder knows that CA identi=
fied in the request 

        
    =
     has no record of ever having issued a c=
ertificate with the 

        
    =
     certificate serial number present in th=
e request, as defined 

        
    =
     in section 2.2.
        
 
<=
/span>

No. Again, this changes the scope of the extension=
 and its audit properties.
Such change requires WG consensus.



        
Comment 9: Solved, if the
            comment above may be solved.

        
 

        
Comment 20:&nbs=
p; This
            comment is preliminary classified by you as “not broken&#=
8221;.
            However, since you
            asked: “If you don’t replace 4.2.2.3,

            then what really are you missing ?”, I
            will provide you with an answer.

        
 

        
This is the
            wrong way to state the question. Providing an ASN.1 syntax
            as in 4.2.1 is not
            enough: the use of every parameter 

            MUST be explained using English words. So if
            you explain the use of every parameter after the description
            of the ASN.1
            syntax 

            in section 4.2.1. then section 4.2.2.3 is no more needed and
            thus can be
            deleted.

        
 

        
The answer
            to your question “what is really missing” is a desc=
ription
            of the use of every
            parameter listed in the ASN.1 in section 4.2.1

        
 
<=
/span>

There are sufficient descriptions in the subsectio=
ns following the ASN.1 description. Your change proposals are not compatible=
 with the minimalistic approach adopted by the WG.

=


        
Comment 21.

        
 

        
While I can
            agree in general with the intent of the text, I do not
            understand the first
            sentence of the Note which speaks of “CA key rolloverR=
21; 

            and is copied below:

        
 

        
   Note=
: CA key rollover is not prohibited when issuing a certificate

        
    =
     for an authorized responder for backwards co=
mpatibility with

        
    =
     RFC 2560 [RFC2560]. That is, it is not prohi=
bited to issue a

        
    =
     certificate for an authorized responder usin=
g a different

        
    =
     issuing key than the key used to issued the =
certificate being

        
    =
     checked for revocation. However, such practi=
ce is strongly

        
    =
     discouraged since clients are not required t=
o recognize a

        
    =
     responder with such certificate as an author=
ized responder.

        
 

        
I would
            propose to delete it, since it does not add anything and
            thus to have:

        
 

        
   Note=
: For backwards compatibility with RFC 2560 [RFC2560], it is 

        
    =
     not prohibited to issue a certificate f=
or an authorized 

        
    =
     responder using a different issuing key=
 than the key used to 

        
    =
     issued the certificate being checked fo=
r revocation. 

        
    =
     However, such practice is strongly disc=
ouraged since clients 

        
    =
     are not required to recognize a respond=
er with such 

        
    =
     certificate as an authorized responder.=


        

I agree, your text is better. Updated.

<=
p class=3D"MsoNormal">=
 

        
Comment 24: The ASN.1
            module in annex B.1 is still wrong,
            since it does not define NoCheck. 

        
 
<=
/span>

No you are wrong. We have confirmed with several A=
SN.1 experts that definition of NoCheck is not necessary to define null cont=
ent.
The current definition is perfectly valid ASN.1

        
Comment 26: You asked for
            explanations. Let me provide
            you with an example when CRLs are being used by the OCSP
            responder 

            in the
            background. The OCSP responder needs to make sure that the
            CRL it uses is
            valid. If it is simply using published CRLs 

            (i.e. no trusted link with the CA),
            it needs to make sure that the CA which has issued the CRL
            has no been revoked.

        
 
<=
/span>

No, this is a misstatement. You don't revoke CAs. =
You revoke CA certificates. There might be a CA certificate that has been re=
voked for a reason that does not affect the OCSP responder.
These =
are operational policies that are outside the scope of the protocol.

The proposed text in comment 26 is plain wrong, or at leas=
t misleading. The OCSP responder does not have to validate the CRL up to any=
 particular root. It may for example have been configured to directly trust =
the public key used to validate the CRL.


=


        
In France,
            there is a root CA for the Administration. However, the use
            of that root CA is
            optional. Thus a Ministry may have its own root, 

            but may also have its key
            certified by the root CA of the Administration. The OCSP
            responder may use the
            root CA of the Ministry, 

            while a relying party may use the root CA of the
            Administration (or the reverse) to validate the CRL for the
            target certificate.
            

            Thus the revocation status will be different if the
            certificate of the CA of
            the Ministry is revoked by the root CA of the
            Administration.

        
 
<=
/span>

Which reinforces my point. How the OCSP responder =
is configured to trust its information source is outside the scope of the pr=
otocol.

The OCSP protocol never claims to provide t=
he same conclusion about revocation than another source the relying party ma=
y use.

I skip category 3 as this will be dealt with=
 in IESG last call.



        
CATEGORY 3=


        
 

        
Comments 2, 3, 7, 10,
            12, 14, 15, 16, 17, 25 and 27.

        
 

        
 

        
CATEGORY 4=


        
 

        
Page 4. The
            indentation of the bullets in section 1 is not uniform. 

            Bullets 1, 4, 5 and 9 have problems.

        
 

        
Page 4. The
            fact that there is now an Annex B.2 dealing with the 2008
            ASN.1 syntax is
            missing. This should be added.

        
 

        
Page 10.
            Change “Se
              further section 4.2.2.2” into “See
              further section 4.2.2.2”

            

        


Thanks. I have fixed them all.

/St=
efan



          Denis

          

        
 

        
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
              

            

      

    

    
=

      
Denis,

      


      

      
Responding to your
        comments below.

      


      

      
However, one
        general remark to make recurring comments easier to understand.
      


      

      
The WG decided to
        adopt a minimalistic approach to updating RFC 2560. That means
        that 

      
    
        
  1. We don't change anything from RFC 2560 unless it is broken,
          or the industry clearly need clarifications in order to avoid
          interoperability issues.
    2. 
        
  2. We retain the document structure of RFC 2560 as much as
          possible to allow easy comparison of what the changes are in
          comparison with RFC 2560.
    3. 
      

      


      

      
One can always
        think up more clever ways to write things out in words. But that
        also comes with a risk.

      
The current words
        has been around for a long time and we know from experience
        which words worked to produce working implementations, and which
        did not.

      
Introducing new
        ways to say the same thing may introduce new problems and people
        might disagree on what the new perfect wording should be. And
        this could go on forever.

      


      

      
So when my reply
        is "Not broken", then that is because the current wording does
        not have such problems that is merits a change.

      


      

      


      

      


      

      
        
From:  Denis Pinkas <denis.pinkas@bull.net>

          Date:  Sunday, January
          20, 2013 5:12 PM

          To:  Stefan Santesson
          <st=
efan@aaa-sec.com>,
          Stephen Kent <kent@bbn.com>

          Cc:  pkix <pkix@ietf.org>

          Subject:  Re: [pkix]
          Review of 2560-bis draft 8. Answer to WGLC

        

        


        

        

          

            
            
 
 
  Normal
  0
  21
  
  
  false
  false
  false
  
   
   
   
   
   
  
  MicrosoftInternetExplorer4
 

                
                
Please find 32 comments on draft-ietf-pkix-rfc2560bis

                
 

                
1. The
                    document states:

                
&n=
bsp;<Cut away issue 1 regarding authorship
                    etc, as it has been responded to separately><=
/p>
              

          

        

      
      


      

      
Responded to
        separately.

      


      

      
        

          

            

                

                
 

                
 

                
2. The
                    current text from section 2 states:
                
 

                
2.<=
span style=3D"mso-spacerun:yes">  Protocol Overview

                
 

                
   In lieu of or as a supplemen=
t to checking against a periodic CRL, it

                
   may be necessary to obtain <=
b style=3D"mso-bidi-font-weight:normal">timely information regarding the

                
   revocation status of a certi=
ficate (cf. RFC5280], Section 3.3).

                
   Examples include high-value =
funds transfer or large stock trades.

                
 

                
   The Online Certificate Statu=
s Protocol (OCSP) enables applications to

                
   determine the (revocation) s=
tate of an identified certificate. OCSP

                
   may be used to satisfy some =
of the operational requirements of

                
   providing more timely revocation information than is possible=
 with

                
   CRLs and may also be used to=
 obtain additional status information. 

                
 

                
This text is misleading because readers may think tha=
t OCPS necessarily provides “timely information”.

                
 

              

          

        

      
      


      

      
"may" does not
        mean "necessarily".

      


      

      
        

          

            

                
Proposed text replacement:

                
 

                
   The Online
                      Certificate Status Protocol (OCSP) is a
                      client-server 

                
   protocol
                      which enables applications to obtain the
                      revocation status 

                
   of one or
                      more certificates either "good", "revoked", or
                      "unknown".

                
=
 

                
   The
                      revocation status may be provided by the server
                      either using a 

                
   real time
                      access to a database of issued certificates, or
                      using a 

                
   batch access
                      to a database of issued certificates, or using a 

                
   real time
                      access to a database of revocation statuses of
                      issued 

                
   certificates,
                      or using a batch access to a database of
                      revocation 

                
   statuses of
                      issued certificates, or using CRLs, or using a <=
/o:p>

                
   combination
                      of base CRLs and delta CRLs.
                
=
 

                
   In the first
                      case, it is possible to obtain timely revocation
                      status 

                
   information,
                      whereas in the other cases, the freshness of the 

                
   revocation
                      status is not better than the mechanisms it is
                      based on.

                
 

                
 

              

          

        

      
      


      

      
Not broken

      


      

      
        

          

            

                
3. The
                    current text from section 2 states:
                
 

                
   An OCSP client issues a stat=
us request to an OCSP responder and 

                
   Suspends acceptance of =
the certificate in question until=
 the 

                
   responder provides a re=
sponse.

                
 

                
   This protocol specifies the =
data that needs to be exchanged between

                
   an application checking the =
status of a certificate and the server

                
   providing that status.<=
/o:p>

                
 

                
Thus is insufficient for an overview. More details ar=
e needed to know what the document provides, 
in particular that the request may contain several requests for several cer=
tificates issued by different CAs. 
The possibility of using extensions should also be advertised.

                
 

                
Proposed text replacement:

                
 

                
 &nbs=
p; When using
                    OCSP, an OCSP client issues a certificate revocation
                    

                
 &nbs=
p; status request
                    to an OCSP responder for one or
                      more certificates 

                
   issued by
                      the same CA or for one or more certificates issued
                      by 

                
   different
                      CAs and
                    then suspends acceptance of the certificate(s) 

                
 &nbs=
p; in question
                    until the responder provides a response.

                
 

                
 &nbs=
p; This document
                    specifies the data that needs to be exchanged
                    between

                
 &nbs=
p; an application
                    checking the status of a certificate and the server

                
 &nbs=
p; providing that
                    status.  

                
 

                
   OCSP may
                      also provide additional status information using 

                
   extensions.
                      

                
 

                
 

              

          

        

      
      


      

      
Not broken

      


      

      
        

          

            

                
4. Page
                    6. Editorial. Punctuation and a CR/LF are missing.=


                
 

                
The
                    text states:

                
 

                
   3. t=
he request contains the information needed by the responder If

                
    =
  any one of the prior conditions are not met, the OCSP responde=
r

                
    =
  produces an error message; otherwise, it returns a definitive<=
o:p>

                
    =
  response.

                
 

                
It
                    should state:

                
 

                
   4. t=
he request contains the information needed by the responder.

                
 

                
      If any one of the prior=
 conditions are not met, the OCSP responder

                
    =
  produces an error message; otherwise, it returns a definitive<=
o:p>

                
    =
  response.

                
 

                
 

              

          

        

      
      


      

      
Fixed in draft 10.
      


      

      
        

          

            

                
5. On
                    page 7, the text states:

                
&n=
bsp;

                
   All
                      definitive response messages SHALL be digitally
                      signed. The key

                
   used to sign
                      the response MUST belong to one of the following:

                
 

                
   -  the CA who issued the certificate in question
                
   -  a Trusted Responder whose public k=
ey is trusted by the requester

                
   -  a CA Designated Responder (Authori=
zed Responder) who holds a

                
    =
  specially marked certificate issued directly by the CA, indica=
ting

                
    =
  that the responder may issue OCSP responses for that CA.<=
/o:p>

                
&n=
bsp;

                
The
                    paragraph is ambiguous on several aspects. <=
/span>

                
 

                
Delegation

                    is addressed in at least three different places, but
                    with different terms and conditions. 

                    If some one picks a sentence in one paragraph rather
                    than another, it will lead to a different
                    conclusion. 

                    RFCs are supposed to be clear.

                
 

                
On
                    page 10, the current text states in section 2.6 OCSP
                      Signature Authority Delegation stat=
es:<=
/o:p>

                
 

                
   The
                        key that signs a certificate's status
                        information need not be the

                
   same

                      key that signed the certificate. A
                      certificate's issuer

                
   explicitly
                      delegates OCSP signing authority by issuing a
                      certificate

                
   containing a
                      unique value for extendedKeyUsage in the OCSP
                      signer's

                
   certificate.
                      This certificate MUST be issued directly to the<=
/o:p>

                
   responder by
                      the cognizant CA.

                
 

                
On page
                    16, there is a section 4.2.2=
.2 called “Auth=
orized
                      Responders”
                    dealing with the same topic. 

                
 

                
Section
                    4.2.2.2 states:

                
 

                
   The
                        key that signs a certificate's status
                        information need not be the

                
   same

                      key that signed the certificate. It
                      is necessary however to

                
   ensure that
                      the entity signing this information is authorized
                      to do

                
   so.  Therefore, a
                      certificate's issuer MAY either sign the OCSP

                
   responses
                      itself or it MAY explicitly designate this
                      authority to

                
   another
                      entity.  O=
CSP

                      signing delegation SHALL be designated by the

                
   inclusion of
                      id-kp-OCSPSigning in an extendedKeyUsage
                      certificate

                
   extension
                      included in the OCSP response signer's
                      certificate.  This

                
   certificate
                      MUST be issued directly by the CA that issued the

                
   certificate
                      in question.

                
 

                
   The CA
                      SHOULD use the same issuing key to issue a
                      delegation

                
   certificate
                      as was used to sign the certificate being checked
                      for

                
   revocation.
                      =
Systems

                        relying on OCSP responses MUST recognize a

                
   delegat=
ion

                      certificate as being issued by the CA that issued
                      the

                
   certifi=
cate

                      in question only if the delegation certificate and
                      the

                
   certifi=
cate

                      being checked for revocation was signed by the
                      same key.<=
/b>

                
 

                
The
                    last sentence above in yellow is the key sentence
                    that is missing in the two other sections.

                
 

                
Most implementations only support the case where the =
OCSP Responder receives an OCSP certificate that is signed by the same key 
that was used to sign the target certificate. They do not support the case =
where the OCSP Responder receives an OCSP certificate 
that is signed by a key that is different from the one that was used to sig=
n the target certificate.

                
 

                
It is
                    inappropriate to have three sections dealing with
                    the same topic with a slightly different meaning.<=
/o:p>

                
 

                
It is
                    proposed the following.

                
 

                
On page
                    7, after:

                
 

                
   -  a CA Designated Responder (Authori=
zed Responder) who holds a

                
    =
  specially marked certificate issued directly by the CA, indica=
ting

                
    =
  that the responder may issue OCSP responses for that CA.<=
/o:p>

                
 

                
it is
                    proposed to add “(see
                      section 4.2.2.2 for further details)=
221;, so
                    that the reader knows that more details are provided
                    later on.

                
 

                
Then
                    we do not need two sections to address delegation
                    which start with the same sentence: 

                  

                


                    “The key t=
hat
                      signs a certificate's status information need not
                      be the same key that signed the certificate”.

                
 

                
It is
                    thus proposed to delete section 2.6.<=
/p>
                
 

                
Section
                    4.2.2.2 will thus remain the single section
                    providing full details.

                
 

                
 

              

          

        

      
      


      

      
I have added
        references to section 4.2.2.2 in the quoted sections in 2.2 and
        2.6.

      
(will be included
        in draft 11)

      


      

      


      

      
        

          

            

                
=
6. Page=
 7, the text states:

                
 

                
   A de=
finitive response message is composed of:

                
 

                
   -  version of the response syntax

                
   -  name of the responder

                
   -  responses for each of the certific=
ates in a request

                
   -  optional extensions

                
   -  signature algorithm OID=


                
   -  signature computed across hash of =
the response

                
 

                
This
                    description does not fit with the ASN.1 syntax which
                    is detailed later on, and in particular:

                
 

                
   ResponseData ::=3D SEQUENCE {

                
      version          =
    [0] EXPLICIT Version DEFAULT v1,
                
      responderID  &=
nbsp;           Res=
ponderID,

                
    =
  producedAt   &nb=
sp;           Gener=
alizedTime,

                
    =
  responses   &nbs=
p;            =
SEQUENCE OF SingleResponse,

                
    =
  responseExtensions   =
[1] EXPLICIT Extensions OPTIONAL }

                
 

                
Proposed text replacement:

                
 

                
   A definitive
                      response message is composed of:

                
=
 

                
   - a response
                      status and if there is no error, the following:<=
/o:p>

                
   - the
                      version of the response syntax,=


                
   - an
                      identifier of the OCSP server,<=
/p>
                
   - the time
                      at which the response was produced,=


                
   - single
                      responses for each of the target certificates,

                
   - optional
                      extensions,

                
   - the
                      signature algorithm OID,

                
   - the
                      signature computed across hash of the response,
                      and

                
   - optional
                      certificates.

                
 

                
 

              

          

        

      
      


      

      
This is an
        overview section. We ought not try to duplicate the level of
        detail provided in the detailed protocol section.

      
A "definitive
        response" according to tho 2.1 is a response to an error-free
        request, so your first remark is redundant.

      


      

      
I have added a
        note about time to the current list, and changed "name" to
        identifier in bullet 2. 

      
(will be included
        in draft 11)

      


      

      
        

          

            

                
7. The
                    text states on page 7:

                
 

                
   The response
                      for each of the certificates in a request consists
                      of

                
 

                
   -  =
target
                      certificate identifier

                
   -  =
certificate
                      status value

                
   -  =
response
                      validity interval

                
   -  =
optional
                      extensions

                
 

                
However,

                    there are no explanations for the purpose of these
                    parameters and how they should be processed.=


                
There
                    are also no explanations on how to process a single
                    response and how to verify that it is its presence
                    within the signed structure 

                    is valid or not valid. This is a major deficiency of
                    the current description of RC 2560 where there is no
                    explanation on how to validate 

                    a single response.

                
 

                
Text
                    proposal to be added after:

                
 

                
   The purpose
                      of the identifier of the OCSP server is to allow
                      OCSP 

                
   clients to
                      find whether the definitive response was signed by
                      a CA 

                
   or by an
                      OCSP Responder.

                
=
 

                
   The
                      identifier of the OCSP server SHOULD either be the
                      name or the 

                
   key from a
                      CA, or the name or the key from a OCSP Responder.

                
=
 

                
   Unless there
                      exist local rules (which are outside the scope of
                      this 

                
   document)
                      for verifying that a single response is correctly
                      signed, 

                
   the
                      following applies:

                
 

                
   When the
                      identifier matches with the name of the CA which
                      has issued 

                
   the target
                      certificate or corresponds to the key used to
                      issue the 

                
   target
                      certificate, then a single response is correctly
                      signed 

                
   only if the
                      digital signature of the OCSP response is valid
                      using the 

                
   key used to
                      sign the target certificate.
                
=
 

                
   When the
                      identifier does not match with the name of the CA
                      which has 

                
   issued the
                      target certificate or does not correspond to the
                      key used 

                
   to issue the
                      target certificate, then an single response is
                      correctly 

                
   signed only
                      if :

                
=
 

                
         <=
/span>(a)
                      there exists in the response an OCSP certificate
                      issued by 

                
        &n=
bsp;    the
                      CA which has issued the target certificate which
                      is 

                
        &n=
bsp;    signed
                      by the same key as the one used to issue the 

                
        &n=
bsp;    target

                      certificate, and

                
=
 

                
         <=
/span>(b)
                      the digital signature of the OCSP response is
                      valid using 

                
        &n=
bsp;    the

                      subjectPublicKey contained in this OCSP
                      certificate.

                
 

                
 

              

          

        

      
      


      

      
Not broken.

      
All of this is
        already covered by the document.

      


      

      
        

          

            

                
8. The
                    text states on page 7:

                
 

                
   The "revo=
ked"
                    state indicates that the certificate has been
                    revoked

                
   (either
                      permanently or temporarily (on hold)). This
                    state MAY also be

                
   returned =
if
                    the responder knows that the requested certificate
                    has

                
   never been
                      issued during the history of the associated CA us=
ing

                    any

                
   current o=
r
                    previous issuing key. 

                
 

                
The
                    text is ambiguous because there are two embedded
                    parenthesis and it is unclear whether the inner
                    parenthesis means “i.e” or “e.g”=
;. 

                    This single sentence may let think that on hold is
                    the single case for temporarily revocation. Since
                    neither X.509 nor RFC 5280 address 

                    the case of a temporary revocation in the context of
                    an OCSP response (but only in the context of CRLs),
                    we are able to add another case 

                    of temporary revocation which will only apply in the
                    context of OCSP.

                
 

                
The
                    above sentence using the terms “neve=
r
                      been issued during the history of the associated
                      CA “does
                    not capture the fact 

                    that it could be issued in the future, hence why
                    using “not yet been used”<=
/b> would
                    be more appropriate.

                
 

                
Finally,
                    it would have been more logical to use “unknown&#=
8221;. So
                    it is important to add a note to explain why we have
                    chosen that case for “legacy clients”, 
=

                    otherwise the people who have not participate to the
                    exchanges will not understand.

                
 

                
Proposed text replacement:

                
 

                
   The "revoked" state indicates that the certificate has been revok=
ed,

                
   eith=
er permanently or temporarily.

                
 

                
   A certificate may be tempora=
rily revoked either because it is 

                
   placed on hold (i.e. the revocation reason is certificateHol=
d) or 

                
   because the responder i=
s able to know, using a positive list of 

                
   issued certificates, th=
at the serial number from the requested 

                
   certificate has not yet been used by the CA to issue a c=
ertificate 

                
   (i.e. the revocation reason is notIssuedOrIrregularlyIssued<=
/b>).

                
 

                
NOTE: The "revoked" state is used rather than the ̶=
0;unknown” state, to

                
    =
  make sure that relying parties that were conformant to RFC 256=
0

                
    =
  will not use CRLs as a fall back mechanism. =


                
 

              

          

        

      
      


      

      
I removed the
        double parenthesis and adopted your clarification with regard to
        "on hold". 

      


      

      
The text in draft
        10 has changed from what you have commented on. I believe that
        text is better.

      


      

      
You "Note" has
        problems.

      
    
        
  1. We do not prevent responders to respond "unknown" if their
          assessment is that this is an appropriate response,
          considering what they know about the requested serial number.
          Thus the term "is used" is misleading.
    2. 
        
  2. This mechanisms does not "make sure" that the clients do
          anything. It's up to the discretion of the relying party to
          decide what source of revocation checking they rely on. This
          does however reduce the risk of clients falling back to CRL:s
        
  3. This mechanism is not just relevant to old clients, but also
          to new one for the same reason.
    4. 
      

      


      

      
I have adopted a
        modified version of your Note:

      


      

      

        
   NOTE: The "revoked" stat=
e for
            known non-issued certificate serial

        
         num=
bers is allowed in
            order to reduce the risk of relying

        
         par=
ties using CRLs as a
            fall back mechanism, which would be

        
         con=
siderably higher if an
            "unknown" response was returned.

      

      


      

      


      

      


      

      
        

          

            

                
 

                
9. The
                    text states on page 8:

                
 

                
   When a
                      responder responds revoked to a status request for
                      a non-

                
   issued
                      certificate, the responder MUST also;

                
 

                
    - include
                      the extended revoked definition response extension

                
      (section
                      4.8), indicating that the OCSP responder supports
                      the

                
      extended
                      definition of revoked state to also cover
                      non-issued

                
      certificates,

                
 

                
    - provide
                      the revocation reason certificateHold (6), and;<=
/o:p>

                
 

                
    - specify
                      the revocation date January 1, 1970. 

                
 

                
As
                    already explained on the PKIX list, using the
                    revocation reason certificateHold is not appropriate 

                    because it changes the meaning of certificateHold. 

                
 

                
The
                    extended revoked definition response extension is a
                    means to signal that it not a true certificate hold
                    but a “not issued certificate”. 

                    Legacy applications cannot take advantage of it. <=
/o:p>

                
 

                
Some
                    applications which handle non repudiation enter a
                    waiting state when the revocation reason
                    certificateHold is used thus 

                    it is not appropriate to overload the meaning.

                
 =


                
It is
                    possible to use another enumeration for signalling
                    that specific case:

                
notIssuedOrIrregularlyIssued

                    (7).

                
 =


                
Thus
                    for new applications it would be much better to use
                    notIssuedOrIrregularlyIssued (7) as already proposed
                    on the PKIX list.

                
 

                
The above sentence uses the text: 
                
 

                
=
220;a status request for a non-issued=
 certificate” 

                
 

                
whereas it would be more appropriate to state:=
 

                
 

                
=
220;a status request for a serial num=
ber which has not been used by the CA or used irregularly to issue a certifi=
cate”.

                
 

                
Placing the ASN.1 description at such a place in the =
document is inappropriate since the ASN.1 structures have not yet been descr=
ibed. 
Thus only the functional aspects should be mentioned, but not the ASN.1 imp=
lications.

                
 

                
BTW, the description should follow the same order as =
the ASN.1. This is not the case. 

                
 

                
This text should be deleted from this section and the=
 appropriate text should be added when the parameters of the response are de=
scribed. 

                
 

                
The text proposed in the previous comment should be s=
ufficient at this time of reading.

                
 

                
In
                    addition, section
                      4.4.8  Ext=
ended

                      Revoked Definition should be deleted.

                
 

                
 

              

          

        

      
      


      

      
The referred text has been updates in draft 09.

      


      

      
This has been discussed on the list and you have yet to
        convince the list of your new reason code.

      
I disagree as the risk of running into problems with the
        deployed base of application is hugely larger with introduction
        of a new reason code, rather than using certificateHold.

      
No application should be broken, since no application have
        business asking for non-issued cert serial numbers in the first
        place. Secondly, no application can assume that a
        certificateHold reason will be cleared any time soon.

      


      

      


      

      
        

          

            

                
10. The
                    text states on page 8:

                
 

                
2.4  Semantics of
                      thisUpdate, nextUpdate and producedAt

                
 

                
This
                    section is misplaced. At this time of reading, the
                    reader does not know that thisUpdate, nextUpdate and
                    producedAt are values 

                    used by the ASN.1 structures. It is appropriate to
                    describe what theses parameters mean when the ASN.1
                    syntax is described. 

                    The current ASN.1 syntax is very badly described.
                    One would expect that after every ASN.1 structure
                    description every parameter is described. 

                    Unfortunately this is not the case. 

                    

                
The
                    text from this section is not aligned with the text
                    that is present in section 4.2.2.1. 
                
 

                
In
                    particular, in section 2.4:

                
 

                
   If
                      nextUpdate is not set, the responder is indicating
                      that newer

                
   revocation
                      information is available all the time.

                
 

                
While
                    in section 4.2.2.1:

                
 

                
   Responses
                      where the nextUpdate value is not set are
                      equivalent 

                
   to a CRL
                      with no time for nextUpdate (see Section 2.4).

                
 

                
It is
                    not appropriate to have two different descriptions
                    in two different places.

                
 

                
Delete
                    section 2.4. See comment number 19 for the
                    description of these parameters.

              

          

        

      
      


      

      
Not broken.

      
The current text segments fits well into a protocol overview
        section.

      


      

      
        

          

            

                
 

                
 

                
11.
                    Section 2.5 is also misplaced. They use values from
                    the ASN.1 syntax which has not yet been described. 
=

                    They should be moved or incorporated in the document
                    once the ASN.1 description has been done.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
 

                
12.
                    Remainder: Section 2.6 should be deleted (see
                    comment number 5).

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
 

                
13.
                    Section 2.7 states:

                
 

                
2.7  CA Key
                      Compromise

                
 

                
   If an OCSP
                      responder knows that a particular CA's private key
                      has

                
   been
                      compromised, it MAY return the revoked state for
                      all

                
   certificates
                      issued by that CA.

                
 

                
This
                    section is misleading and should be removed. The
                    reason is the following:

                
 

                
The
                    relying party must verify that the singleResponse is
                    signed by a responder which is entitled to do so.<=
/o:p>

                
 

                
a) If
                    the CA key has been compromised and if the response
                    is signed by that CA key then the singleResponse
                    will be discarded 

                    when performing the certification path validation wh=
atever
                      the content of the response may be.

                
 

                
b) If
                    the CA key which has issued the OCSP certificate has
                    been compromised and if the response is signed by
                    the key present 

                    in the OCSP certificate then the singleResponse will
                    be discarded when performing the certification path
                    validation

                    whatever the content of the response may be.

                
 

                
 

                
Security

                    must be provided using the validation of the
                    certification path. Thus it does not matter what the
                    OCSP responder states.

              

          

        

      
      


      

      


      

      
Not broken.

      
An OCSP responder does not have to be chained to the broken
        CA. The relying party may have other trust configuration at
        choice.

      


      

      


      

      
        

          

            

                


                

                
 

                
14. The
                    text states on page 11:

                
 

                
3.2  Signed
                      Response Acceptance Requirements

                
 

                
   Prior to
                      accepting a signed response as valid, OCSP clients
                      SHALL

                
   confirm
                      that:

                
 

                
   1. The
                      certificate identified in a received response
                      corresponds to

                
      that
                      which was identified in the corresponding request;

                
 

                
   2. The
                      signature on the response is valid;=


                
 

                
   3. The
                      identity of the signer matches the intended
                      recipient of the

                
      request.

                
 

                
   4. The
                      signer is currently authorized to sign the
                      response.

                
 

                
   5. The time
                      at which the status being indicated is known to be

                
      correct
                      (thisUpdate) is sufficiently recent.

                
 

                
   6. When
                      available, the time at or before which newer
                      information will

                
      be
                      available about the status of the certificate
                      (nextUpdate) is

                
      greater
                      than the current time.

                
 

                
This
                    section is misplaced since it uses terms from the
                    ASN.1 syntax and the protocol description has not
                    yet been made, 

                    since it is the next section 4. Its text is not
                    correct either. 

                
 

                
This
                    description does not take into account the fact that
                    a BasicOCSPResponse may
                    contain one or several SingleResponses. 

                    In particular, the sentence “The signer is currently
                      authorized to sign the response” is
                    misleading because a signer 

                    may be authorized to include some SingleResponses but not
                    necessarily all of them. 

                
 

                
The
                    appropriate explanations should be done after the
                    description of the response, when describing the
                    processing of the response.

                
 

                
Delete
                    that section.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
 

                
15. On
                    page 12, after the ASN.1 description, the only
                    parameters which are described are: <=
/p>
                
hashAlgorithm,=
 issuerNameHash,

                      issuerKeyHash and serialNumber.=


                
 

                
This
                    is insufficient.  <=
/span>In
                    order to cover the full list of parameters, the
                    following text is proposed:

                
 

                
   requestorName
                      is optional and MAY be used by the server for
                      access 

                
   control and
                      audit purposes.

                
=
 

                
   requestList
                      contains one or more single requests.

                
=
 

                
   requestExtensions
                      is OPTIONAL.  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.

                
=
 

                
   reqCert
                      contains the identifier of a target certificate.=


                
=
 

                
   issuerNameHash
                      is the hash of the Issuer's distinguished name.  The 

                
   hash shall
                      be calculated over the DER encoding of the
                      issuer's name 

                
   field in the
                      certificate being checked. 
=

                
=
 

                
   issuerKeyHash
                      is the hash of the Issuer's public key.  The hash 

                
   shall be
                      calculated over the value (excluding tag and
                      length) of the 

                
   subject
                      public key field in the issuer's certificate.  The hash 

                
   algorithm
                      used for both these hashes, is identified in 

                
   hashAlgorithm.
                      

                
=
 

                
     &nb=
sp;The primary
                      reason to use the hash of the CA's public key in 

                
      addition
                      to the hash of the CA's name, to identify the
                      issuer, 

                
      is that
                      it is possible that two CAs may choose to use the
                      same 

                
      name
                      (uniqueness in the Name is a recommendation that
                      cannot be 

                
      enforced).

                      Two CAs will never, however, have the same public
                      key 

                
      unless
                      the CAs either explicitly decided to share their
                      private 

                
      key, or
                      the key of one of the CAs was compromised.=


                
=
 

                
   serialNumber
                      is the serial number of the certificate for which
                      

                
   status is
                      being requested.

                
=
 

                
   singleRequestExtensions

                      is OPTIONAL.  Any

                      specific extension is 

                
   OPTIONAL.  The critical
                      flag SHOULD NOT be set for any of them. 

                
=
 

                
   The
                      requestor MAY choose to sign the OCSP request.  In that case,
                      the

                
   signature is
                      computed over the tbsRequest structure.  If the
                      request

                
   is signed,
                      the requestor SHALL specify its name in the
                      requestorName

                
   field.  Also, for
                      signed requests, the requestor MAY include=


                
   certificates
                      that help the OCSP responder verify the
                      requestor's

                
   signature in
                      the certs field of Signature.
                
 

              

          

        

      
      


      

      
Not broken.

      
The current text is short, but it is actually sufficient from
        the context of the ASN.1 definitions of the section. This is a
        detailed protocol section and the reader need to understand
        ASN.1 in any case to understand and implement the section.

      
The information about criticality is already covered in the
        extension section.

      


      

      


      

      
        

          

            

                
 

                
16.
                    Section 4.1.2 is called: “N=
otes on the
                      Request Syntax”

                
 

                
The
                    first paragraph has been moved after the description
                    of issuerKeyHash and
                    thus is no more needed.

                
 

                
The
                    second paragraph has been moved after the
                    description of requestExtensions. 

                    However, the sentence 

                    “ =
Unrecognized extensions MUST
                      be ignored (unless they have the critical flag set
                      and are not understood)” 

                    has been deleted since it applies to the OCSP
                    responder and not to the OCSP client. Thus it is no
                    more needed.

                
 

                
The
                    third paragraph applies to signed requests. However,
                    it should belong to a section dedicated on how
                    clients should build OCPS requests, 

                    which is currently missing. See the next comment.<=
/o:p>

                
 

                
This
                    section should be deleted.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
 

                
17. There
                    should be a new section called: “Requi=
rements

                      for OCSP clients”. 

                
 

                
It is
                    important first to re-advertise that the request may
                    be about several certificates. 

                    Thus it is important to describe the process for
                    building a request, which is currently missing.

                
 

                
   An OCSP
                      request allows getting in the same response the
                      revocation 

                
   status of
                      one or more certificates.  In order to
                      request the 

                
   status of
                      one or more certificates in a single request, OCSP
                      

                
   clients
                      SHALL follow the following rules :<=
/b>

                
=
 

                
   For each
                      candidate certificate, OCSP clients SHALL verify 

                
   whether
                      there exists a locally defined rule for the
                      certificate in 

                
   question
                      which indicates the URI where the OCSP responder
                      is 

                
   located.  If this rule
                      exists, it SHALL be followed. <=
/p>
                
=
 

                
   Otherwise,
                      OCSP clients SHALL determine whether the candidate
                      

                
   certificate
                      contains an AIA extension with an accessMethod
                      which 

                
   contains the
                      id-ad-ocsp OID.  =
If

                      it is the case, the accessLocation =


                
   contains a
                      uniformResourceIdentifier (URI) which indicates
                      the 

                
   location of
                      the OCSP server for that certificate. 

                
=
 

                
   Certificates
                      that contain the same URI MAY be grouped in a
                      single 

                
   request.=


                
=
 

                
Note:=
  For each
                      candidate certificate, when performing the path =


                
       valida=
tion

                      algorithm, the OCSP client SHOULD verify that the
                      

                
       curren=
t
                      time is within the validity period of the target 

                
       certif=
icate.  Certificates
                      which are outside their validity 

                
       period=

                      SHOULD NOT be included in the request.

                
 

                
   The
                      requestor MAY choose to sign the OCSP request. In
                      that case, the

                
   signature is
                      computed over the tbsRequest structure. If the
                      request

                
   is signed,
                      the requestor SHALL specify its name in the
                      requestorName

                
   field. Also,
                      for signed requests, the requestor MAY include

                
   certificates
                      that help the OCSP responder verify the
                      requestor's

                
   signature in
                      the certs field of Signature.
                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
Your text may provide guidance that could be useful to some
        implementers, but is completely beyond this document and
        further, not generally applicable or true.

      
As an example, an organisation may setup an in house locally
        configured OCSP responder that responds to all certificates "out
        there" that is relevant to that organisation.

      
Such clients would just blindly send OCSP requests to their
        local responder, disregarding any information in the cert.

      
It's totally beyond this spec to have an opinion about this.
      


      

      


      

      
        

          

            

                
 

                
18. The
                    text states on page 14:

                
 

                
   The
                      responder MAY include certificates in the<=
/span>

                
   certs field
                      of BasicOCSPResponse that help the OCSP client
                      verify the

                
   responder's
                      signature. If no certificates are included then
                      certs

                
   SHOULD be
                      absent.

                
 

                
While
                    this sentence is true, it is not sufficient. In
                    order to allow verifying every SingleResponse, 

                    it is important to include the relevant certificates
                    which are pertinent to every Sing=
leResponse.

                
 

                
Proposed

                    full text replacement:

                
 

                
   The respo=
nder
                    MAY include certificates in the certs field of 

                
   BasicOCSP=
Response

                    that help the OCSP client verify the responder's <=
/o:p>

                
   signature=
.

                
 

                
   For every
                      SingleResponse where the responder is not a CA,
                      the 

                
   responder
                      SHALL include the relevant OCSP certificate in the
                      certs 

                
   field of
                      BasicOCSPResponse in order to allow the OCSP
                      client 

                
   verifying
                      the responder was entitled to include that
                      SingleResponse 

                
   in the
                      signed BasicOCSPResponse.

                
=
 

                
   If
                    no certificates are included then certs SHOULD be
                    absent.

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
This requirement would break backwards compatibility with RFC
        2560.

      
Further this would not be needed for a locally configured
        responder.

      


      

      
        

          

            

                
 

                
19. Page
                    15. The ASN.1 syntax should be changed in order to
                    be able to use the enumeration case 7 that is not
                    used for CRLs. 

                    This leads to the following change:
                
 

                
Current
                    text:

                
 

                
       revocationReason    [0]     EXPLICIT
                      CRLReason OPTIONAL }

                
 

                
Proposed

                    text change:

                
 

                
Revoc=
ationReason
::=3D

                      ENUMERATED {

                
        =
unspecified     &nbs=
p;       =
;      &=
nbsp;(0),

                
        =
keyCompromise     &n=
bsp;      &nb=
sp;     (1),

                
        =
cACompromise     &nb=
sp;      &nbs=
p;      =
(2),

                
        =
affiliationChanged    <=
span style=3D"mso-spacerun:yes">         (3),

                
        =
superseded      =
;       =
        (4),

                
        =
cessationOfOperation           (5),

                
        =
certificateHold     =
       &=
nbsp;   (6),

                
        =
notIssuedOrIrregularlyIssued

                        (7)=
,

                
        =
removeFromCRL     &n=
bsp;      &nb=
sp;     (8),

                
        =
privilegeWithdrawn           &nbs=
p; (9),

                
        =
aACompromise     &nb=
sp;      &nbs=
p;     (10) }

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
You have to convince the list about your new reason code.

      


      

      
        

          

            

                
 

                
20.
                    Page 15. After the ASN.1 syntax, there is no
                    description of every parameter, neither on its use 
=

                    (except a few words in section 4.=
2.2.1 Time
                    about=
 thisUpdate,
                      nextUpdate and producedAt).
=

                
 

                
Every
                    parameter needs to be described and explained.

                
 

                
   responderID
                      indicates either the name or the key from a CA, or
                      the 

                
   name or the
                      key from a OCSP Responder.

                
=
 

                
   producedAt
                      indicates the time at which this response was
                      signed.

                
=
 

                
   responses
                      contains one or more single responses.

                
=
 

                
   responseExtensions
                      is OPTIONAL.  Any

                      specific extension is OPTIONAL.=


                
   The critical
                      flag may or may not be set.
=

                
=
 

                
   certID is
                      usually a copy of the same field which was placed
                      in the 

                
   request, but
                      for OCSP responders which pre-produce signed
                      responses 

                
   certID may
                      be the identifier of a target certificate that was
                      not 

                
   present in
                      the request (see the end of section 4.2).<=
/span>

                
=
 

                
   certStatus
                      indicates the status of the certificate: either
                      good, 

                
   revoked or
                      unknown.

                
=
 

                
   thisUpdate
                      indicates the time at which the status being
                      indicated 

                
   is known to
                      be correct.

                
=
 

                
   nextUpdate
                      indicates the time at or before which newer
                      information 

                
   will be
                      available about the status of the certificate.  If 

                
   nextUpdate
                      is not set, the server is indicating that newer =


                
   revocation
                      information is available all the time. 

                
=
 

                
   If
                      nextUpdate is set, it often corresponds to the
                      {thisUpdate, 

                
   nextUpdate}
                      interval in CRLs. =
;
                      Responses whose nextUpdate value is 

                
   earlier than
                      the local UTC time value SHOULD be considered 

                
   unreliable.  Responses
                      whose thisUpdate time is later than the local 

                
   UTC time
                      SHOULD be considered unreliable.

                
=
 

                
   singleExtensions
                      is OPTIONAL.  Any

                      specific extension is OPTIONAL.=


                
   The critical
                      flag SHOULD NOT be set for any of them.

                
=
 

                
   revocationTime

                      indicates the time at which the certificate was =


                
   revoked.=


                
=
 

                
   revocationReason
                      is OPTIONAL.  It

                      includes all the cases that are 

                
   present in
                      CRLReason used for CRLs and an additional case 7
                      which is

                
   not used for
                      CRLs.  Cas=
e
                      7 is called notIssuedOrIrregularlyIssued. =


                
=
 

                
      -
                      "notIssued" corresponds to the case where the
                      certificate 

                
         <=
/span>serial
                      number that was sent was erroneous and has not yet
                      

                
         <=
/span>been
                      used by the CA at the time of the query,

                
=
 

                
      -
                      "irregularlyIssued" corresponds to the case where
                      the 

                
         <=
/span>certificate

                      serial number that was sent really exists in a <=
/o:p>

                
         <=
/span>certificate
                      that is correctly signed, but to its knowledge <=
/o:p>

                
         <=
/span>the CA
                      has not issued a certificate with such a serial =


                
         <=
/span>number.
                       As an
                      example, it may have been issued by the CA 

                
         <=
/span>because
                      the RA was compromised. 

                
=
 

                
   When=
 a responder responds revoked to a status request for which it 

                
   knows that the serial number has not been used by the CA or has =


                
   been irregularly used irregularly to issue a certificate, then <=
/span>

                
   in RevokedInfo the responder MUST:

                
 

                
      - specify the revocationTime :=
  January 1, 1970,

                
     =
; - provide the revocation=
Reason: notIssuedOrIrregularlyIssued (7).

                
 

                
   and in SingleResponse the responder MUST =
NOT include the nextUpdate.

                
=
 

                
   The response
                      MUST include a SingleResponse for each certificate
                      in

                
   the request
                      and SHOULD NOT include any additional
                      SingleResponse

                
   elements.  However,
                      there is one exception: 

                
 

                
      OCSP
                      responders MAY pre-produce signed responses
                      specifying the 

                
      status of
                      certificates at a specified time.  The time at
                      which 

                
      the
                      status was known to be correct SHALL be reflected
                      in the 

                
      thisUpdate
                      field of the response. 

                
=
 

                
      OCSP
                      responders that pre-generate status responses MAY
                      return 

                
      responses
                      that include additional SingleResponse elements if

                
      necessary
                      to improve response pre-generation performance or
                      cache

                
      efficiency
                      (as permitted in [RFC5019]).
                
 

                
Since
                    the text above provides all the explanations at the
                    level of the ASN.1 parameters, the general text 

                    from section
                      4.2.2.3 Basic Response is
                    no more need and should be deleted.

                
 

              

          

        

      
      


      

      
Preliminary I would say "not broken".

      
If you don't replace 4.2.2.3, then what really are you
        missing?

      


      

      
        

          

            

                
 

                
21. 0n
                    page 16, there is a section 4=
.2.2.2 called “Authorized Responders”

                
 

                
Section
                    4.2.2.2 states:

                
 

                
   (…)

                
   This
                      certificate MUST be issued directly by the CA that
                      issued the

                
   certificate
                      in question.

                
 

                
   The CA
                      SHOULD use the same issuing key to issue a
                      delegation

                
   certificate
                      as was used to sign the certificate being checked
                      for

                
   revocation.
                      Systems relying on OCSP responses MUST recognize a

                
   delegation
                      certificate as being issued by the CA that issued
                      the

                
   certificate
                      in question only if the delegation certificate and
                      the

                
   certificate
                      being checked for revocation was signed by the
                      same key.

                
 

                
This
                    section would need to reformatted to address CA
                    requirements first and then OCSP responder
                    requirements:

                
 

                
   (…)

                
   This
                      certificate MUST be issued directly by the CA that
                      issued the

                
   certificate
                      in question.  The
                      CA SHOULD use the same issuing key to 

                
   issue a
                      delegation certificate as was used to sign the
                      certificate 

                
   being
                      checked for revocation. 

                
 

                
   Systems
                      relying on OCSP responses MUST be able to
                      recognize a 

                
   delegation
                      certificate as being issued by the CA that issued
                      the 

                
   certificate
                      in question if the delegation certificate and 

                
   the
                      certificate being checked were signed by
                      the same key.

                
 

              

          

        

      
      


      

      
I disagree. The CA is actually free to do anything, but
        cannot expect the client to recognise the responder as
        authorised unless the same private key is used.

      
The current text places the requirement where they belong.
=

      


      

      
        

          

            

                
 

                
22. On
                    page 17, the text states:

                
 

                
   They MUST
                      reject the

                
   response if
                      the certificate required to validate the signature
                      on the

                
   response
                      fails to meet at least one of the following
                      criteria:

                
 

                
This
                    is ambiguous. It is inappropriate to have a negative
                    statement like “They MUST
                      reject”. 

                    The sentence should be turned in the positive form “They
                      SHALL accept” 

                
 

                
Since
                    the ASN.1 syntax has now be described, it is
                    possible to be more specific.

                
 

                
The
                    first occurrence of the word “response” sho=
uld be
                    changed into “singleResponse”, while the se=
cond
                    occurrence 

                    of the word “response” should be changed in=
to
                    “ResponseData”

                
 

                
Proposed

                    text replacement:

                
 

                
   They SHALL
                      accept a singleResponse if the certificate
                      required to 

                
   validate the
                      signature placed on the ResponseData meets one of
                      the 

                
   following
                      criteria:

              

          

        

      
      


      

      


      

      
No, this change is not backwards compatible.

      
So state the requirements for rejection is not equivalent to
        stating requirements for acceptance.

      
There may be other locally configured reasons to reject in
        addition to those listed in the standard.

      


      

      


      

      
        

          

            

                
 

                
 

                
23. On
                    page 17, the text states:

                
 

                
   3. Includes
                      a value of id-kp-OCSPSigning in an
                      ExtendedKeyUsage

                
   extension
                      and is issued by the CA that issued the
                      certificate in

                
   question as
                      stated above."

                
 

                
In
                    order to be crystal clear, it is proposed to change
                    the wording in the following way:
=

                
 

                
   3. Includes
                      a value of id-kp-OCSPSigning in an
                      ExtendedKeyUsage

                
   extension
                      and was signed by the CA using the same key that
                      used 

                
   to issue the
                      certificate in question.

                
 

              

          

        

      
      


      

      
No, issuing with another key is not prohibited, and may be
        accepted by some clients as an authorised responder.

      


      

      
        

          

            

                
 

                
24. On
                    page 17, the text states:

                
 

                
   This SHOULD
                      be a non-critical extension. The value of the
                      extension 

                
   SHALL be
                      NULL.

                
 

                
The
                    ASN.1 syntax is missing. Add: 

                
 

                
   NoCheck ::=3D
                      NULL

                
 

                
 

              

          

        

      
      


      

      
Moving this to a separate discussion.

      
I'm not sure what the preferred way to describe this is.

      


      

      


      

      
        

          

            

                
25.
                    Remainder: On page 18, the general text from section 4.2.2.3 Basic Response is no
                    more needed and 

                    should be deleted. See comment 20.
                
&n=
bsp;

                
 

              

          

        

      
      


      

      
Not broken.

      


      

      
        

          

            

                
26. On
                    page 24, text should be added to the Security
                    consideration section:

                
 

                
Diffe=
rent

                      results when using OCSP and CRLs

                
=
 

                
   OCSP clients
                      or verifiers must build and verify a certification
                      path 

                
   for each
                      target certificate up to a trusted root.  When an OCSP
                      

                
   Responder is
                      using published CRLs, it must also build and
                      verify a 

                
   certification
                      path for the CRLs it uses up to a trusted root.<=
/o:p>

                
=
 

                
   However, it
                      should be realized that the root used by an OCSP 

                
   Responder to
                      verified these CRLs is not necessarily the same as
                      the 

                
   one that
                      would be used by the OCSP client, if it were going
                      to verify 

                
   the CRLs
                      itself.  H=
ence
                      the revocation status may not be identical 

                
   in both
                      cases.

                
=
 

                
=
 

              

          

        

      
      


      

      
I don't understand this one.

      


      

      
        

          

            

                
27. On
                    page 24, text should be added to the Security
                    consideration section:

                
=
 

                
Denia=
l

                      of service attack using a flood of queries=


                
=
 

                
   A denial of
                      service vulnerability is evident with respect to a
                      flood 

                
   of queries.  The
                      production of a cryptographic signature 

                
   significantly
                      affects response generation cycle time, thereby =


                
   exacerbating
                      the situation. 

                
=
 

                
   The flood of
                      queries may either come from a flood attack or
                      from the 

                
   fact that
                      there are too many certificates supported by the
                      same OCSP 

                
   responder.  In the later
                      case, the number of queries can be =


                
   reduced by
                      using a technique similar to the splitting of
                      CRLs: 

                
=
 

                
      When a
                      block of certificates have been issued with the
                      same 

                
      accessLocati=
on
                      in the AIA extension field of these certificates,
                      

                
      then the
                      accessLocation should be changed.  In this way,
                      a given 

                
      OCSP
                      server will only be responsible for a block of
                      certificates.

                
=
 

              

          

        

      
      


      

      
If the security considerations section is talking about
        splitting OCSP responders in this way, then the document itself
        need to introduce the subject.

      
I would suggest that it is beyond this update to do so.

      


      

      
        

          

            

                
=
 

                
28. On
                    page 31, the text states.

                
 

                
   An
                      alternative to this module that conforms to the
                      2002 version of 

                
   ASN.1 may be
                      found in Section 4 of [RFC5912]. 

                
 

                
RFC
                    5912 omits to define the nocheck extension. Thus it
                    is inappropriate to refer to RFC 5912. 

                
 

                
The
                    corrected module should be defined in this new
                    draft. 

                    A corrected module is provided in draf=
t-pinkas-rfc2560bis-03.

                
 

              

          

        

      
      


      

      
Will move this (as stated above) to a separate discussion.
=

      


      

      
        

          

            

                
 

                
29.
                    Different topics are not covered by the document.
                    These topics are important. 

                    The following comments propose text to be placed in
                    annexes. Three annexes are being proposed.

                
 

                
Note:
                    The texts are extracted from draf=
t-pinkas-rfc2560bis-03.

                
 

                
 

              

          

        

      
      


      

      
Not broken.

      
Each such amendment need to be thoroughly reviewed and
        motivated.

      


      

      


      

      
        

          

            

                
30. First
                    annex being proposed. This annex is important,
                    because key rollover is not addressed in the draft.

                
 

                
KEY

                      ROLLOVER

                
=
 

                
1.
                      CA that directly supports an OCSP service<=
/span>

                
=
 

                
   When a CA
                      that directly supports an OCSP service performs a
                      key 

                
   rollover:

                
=
 

                
   - for
                      certificates issued under the old key, the CA
                      SHALL continue 

                
     to sign
                      the revocation status of OCSP responses with that
                      old key 

                
     at least
                      until all these certificates are expired, and

                
=
 

                
   - for
                      certificates issued under the new key, the CA
                      SHALL change the 

                
     accessLocation
                      in the AIA extension field of these certificates 

                
     and sign
                      the revocation status of OCSP responses with that
                      new key 

                
     at least
                      until all these certificates are expired.<=
/span>

                
=
 

                
   Note: The
                      change in accessLocation is necessary when the CA
                      rekeys 

                
         <=
/span>to
                      meet the following constraints imposed by this
                      standard: 

                
=
 

                
        &n=
bsp;   1)
                      a BasicOCSPResponse can only be signed using a
                      single 

                
        &n=
bsp;      private

                      key; 

                
=
 

                
        &n=
bsp;   2)
                      the response must be signed using the same CA key
                      that 

                
        &n=
bsp;      was used to
                      sign the certificate in question; and

                
=
 

                
        &n=
bsp;   3)
                      the OCSP response needs to cover all the
                      certificates 

                
        &n=
bsp;      queried
                      in the OCSP request.

                
 

                
2.
                      CA that uses OCSP responders
                
 

                
   When a CA
                      that uses OCSP Responders performs a key rollover,
                      then 

                
   it MUST
                      either designate a new OCSP Responder or keep the
                      current 

                
   OCSP
                      Responder(s).

                
=
 

                
   If the CA
                      designates a new OCSP Responder, then it SHALL
                      change the 

                
   accessLocation
                      in the AIA extension field for the newly issued =


                
   certificates
                      and issue an OCSP certificate to the new OCSP
                      Responder 

                
   using its
                      new key.

                
=
 

                
   If the CA
                      keeps the same OCSP Responder(s), then it SHALL
                      continue 

                
   to use the
                      same accessLocation(s) in the AIA extension field
                      for the 

                
   newly issued
                      certificates and issue an OCSP certificate to the
                      

                
   appropriate
                      OCSP Responder(s) using its new key.

                
=
 

                
   Note: The CA
                      may need to continue issuing certificates to the
                      OCSP 

                
   Responder(s)
                      using the old CA key until all the certificates
                      issued 

                
   under the
                      CA' old key for which the OCSP Responder(s) are =


                
   authoritative
                      have expired.

                
=
 

                
3.
                      OCSP Responder key rollover
=

                
=
 

                
   When an OCSP
                      Responder performs a key rollover (asynchronously
                      from 

                
   a CA key
                      rollover), then each CA which has designated an
                      OCSP 

                
   Responder
                      SHALL issue a new certificate for that OCSP
                      Responder and 

                
   for each of
                      its issuing keys which meets the following
                      property: 

                
=
 

                
      - the
                      issuing key has been used to sign at least one
                      certificate 

                
        =
which
                      contains an AIA extension designating that OCSP
                      Responder 

                
        =
and
                      that certificate is not yet expired.

                
=
 

                
   An OCSP
                      Responder key rollover does not affect the values
                      of the 

                
   URIs that
                      are placed in the accessLocation field from the
                      target 

                
   certificates.  One or more
                      OCSP Responder MAY respond to an OCSP 

                
   request
                      addressed at a given URI picked from the
                      accessLocation 

                
   field from a
                      target certificate.&nb=
sp;
                      Each OCSP Responder MAY use a 

                
   different
                      signing key, as long as it got an OCSP certificate
                      

                
   appropriate
                      for that signing key and for the target
                      certificate. 

                
 

                
 

                
31. Second
                    annex being proposed. This annex is important
                    because it describes the validation of an OCSP
                    response in the past 

                    which is of a particular importance when validating
                    electronic signatures.

                
 

                
Respo=
nse

                      processing by an OCSP client
                
=
 

                
   OCSP
                      responses can be verified at the current time by
                      an OCSP client 

                
   when
                      receiving a response, whereas old responses can be
                      verified at 

                
   a time in
                      the past by a verifier.  The algorithm
                      below addresses 

                
   both cases.<=
/b>

                
=
 

                
   Prior to
                      processing a basic response, OCSP clients MUST
                      determine 

                
   the checking
                      time, which may be either the current time or a
                      time 

                
   in the past.=


                
=
 

                
   OCSP clients
                      or verifiers SHALL check if the response contains
                      

                
   responseExtensions.
                      If such an extension is found and is recognized, 

                
   it MUST be
                      processed.  If
                      such a critical extension is found and 

                
   is not
                      recognized, the whole OCSP response MUST be
                      considered as 

                
   invalid.=


                
=
 

                
   If the
                      checking time is the current time, and if a nonce
                      extension 

                
   has been
                      used in the request and is recognized (see section
                      4.5.1), 

                
   OCSP clients
                      MUST check whether the same nonce is present in
                      the 

                
   response.  If the nonce
                      is not present or is different, then the <=
/span>

                
   OCSP
                      response MUST be discarded.
=

                
=
 

                
   Only the
                      single response(s) which are/is of interest SHALL
                      be 

                
   checked.=


                
=
 

                
STEP

                      1

                
=
 

                
   OCSP clients
                      or verifiers SHALL verify that the certificate <=
/o:p>

                
   identified
                      in a single response is of interest.  Otherwise,
                      proceed 

                
   to step 3.

                
=
 

                
   If the
                      certificate status included in a single
                      certificate response 

                
   is
                      "unknown", then the revocation status of that
                      certificate is 

                
   "unknown",
                      and proceed to step 3.

                
=
 

                
   If the
                      certificate status from the single certificate
                      response is 

                
   either
                      "good" or "revoked", OCSP clients or verifiers
                      SHALL check 

                
   that the
                      checking time is within the validity period of the
                      target 

                
   certificate.  If it is not
                      the case, then the revocation status of 

                
   that
                      certificate is "unknown" and proceed to step 3.<=
/o:p>

                
=
 

                
   If the
                      checking time is the current time, and if a nonce
                      has been 

                
   used in the
                      request, then proceed to step 2.

                
=
 

                
   If the
                      checking time is the current time, and if no nonce
                      has been 

                
   used in the
                      request, OCSP clients MUST check that the
                      producedAt

                
   field is
                      within a time window that is "close enough" to the
                      current 

                
   time. 
                
=
 

                
   Note: the
                      notion of "close enough" is a local matter.  It can be set
                      

                
         <=
/span>to a
                      few minutes to allow for small UTC time
                      differences 

                
         <=
/span>between
                      the client and the server or to a few hours in
                      case 

                
         <=
/span>the
                      server is producing pre-computed responses.

                
=
 

                
   If the
                      checking time is a time in the past, verifiers
                      MUST check 

                
   that the
                      producedAt field is in accordance with the
                      verification 

                
   rules (e.g.
                      close and/or after the date of a time-stamp
                      token).

                
=
 

                
   In addition,
                      if the nextUpdate field is present, OCSP clients
                      MUST 

                
   check that
                      the time which is indicated is greater than the
                      checking 

                
   time,
                      otherwise the single response MUST be discarded.=


                
=
 

                
   If checks
                      are successful, then OCSP clients MUST process the
                      

                
   singleExtensions

                      field, if it is present. 

                
=
 

                
   If the
                      criticality flag is set and the extension is not
                      understood, 

                
   then the
                      status of the certificate shall be "unknown" and
                      proceed to 

                
   step 3.  Otherwise,
                      proceed to step 2. 

                
=
 

                
   If the
                      extension is understood, then the extension MUST
                      be 

                
   processed.  According to
                      its content proceed either to step 2 or to 

                
   step 3. =


                
=
 

                
STEP

                      2

                
=
 

                
   OCSP clients
                      or verifiers MUST build and verify a certification
                      path 

                
   for that
                      certificate up to a trusted root, so that they
                      have the 

                
   knowledge of
                      the CA public key value that was used to sign the
                      

                
   target
                      certificate.  The
                      revocation status of each certificate of <=
/span>

                
   that
                      certification path (except the target certificate)
                      SHALL be 

                
   checked.=


                
=
 

                
   If no path
                      can be built or if one of the certificates of the
                      path is 

                
   revoked,
                      then the revocation status of that certificate is
                      "unknown", 

                
   and proceed
                      to step 3. 

                
=
 

                
   If the
                      certification path (except the target certificate)
                      is valid, 

                
   then two
                      cases need to be considered:
                
=
 

                
   a) If the
                      responderID matches with the name or the key from
                      the CA 

                
      which has
                      issued the target certificate, then check whether
                      the 

                
      OCSP
                      response is signed by the same key that was used
                      to sign 

                
      the
                      target certificate.

                
=
 

                
        &n=
bsp;    If
                      it is the case, then the revocation status of that
                      

                
        &n=
bsp;    certificate

                      as indicated in the certStatus field is 

                
        &n=
bsp;    accepted
                      and proceed to step 3.

                
=
 

                
        &n=
bsp;    If
                      it is not the case, then the revocation status of
                      that 

                
        &n=
bsp;    certificate

                      is "unknown" and proceed to step 3.=


                
=
 

                
   b) If the
                      responderID does not match with the name or the
                      key from 

                
      the CA
                      which has issued the target certificate, then it
                      indicates 

                
      the name
                      or the key from an OCSP Responder.  Check whether
                      there 

                
      exists a
                      local rule which applies to this target
                      certificate to 

                
      verify
                      that the signature of the BasicOCSPResponse is
                      valid for 

                
      that
                      single response. =
 If
                      this rule exists, it SHALL be followed. 

                
=
 

                
      Otherwise
                      check whether there is an OCSP certificate (i.e.
                      which 

                
      has both
                      the ocspSigning OID in the extended key usage
                      extension 

                
      and the
                      digitalSignature bit in the key usage extension)
                      signed 

                
      by the
                      same key that was used to sign the target
                      certificate. 

                
      This
                      certificate MUST be present in the certs field
                      from the 

                
      BasicOCSPRes=
ponse.

                      

                
=
 

                
        &n=
bsp; If
                      such certificate is not found or is invalid, then
                      the 

                
        &n=
bsp; revocation

                      status of that certificate is "unknown" and 

                
        &n=
bsp; proceed
                      to step 3.

                
=
 

                
        &n=
bsp; If
                      such certificate exists and if the checking time
                      is 

                
        &n=
bsp; within
                      the validity period of this certificate, then it
                      MUST 

                
        &n=
bsp; be
                      verified whether the OCSP response can be verified
                      using 

                
        &n=
bsp; the
                      public key that is present in the OCSP
                      Certificate. 

                
=
 

                
        &n=
bsp;    If
                      it is not the case, then the revocation status of
                      that 

                
        &n=
bsp;    certificate

                      is "unknown" and proceed to step 3.=


                
=
 

                
        &n=
bsp;    If
                      it is the case, then it MUST be verified that the
                      OCSP 

                
        &n=
bsp;    Certificate

                      has not been revoked.

                
=
 

                
     If one of
                      these conditions is met, then the status for the
                      target 

                
     certificate
                      as indicated in the certStatus field is accepted,
                      

                
     otherwise
                      the revocation status is "unknown".=


                
=
 

                
STEP

                      3

                
=
 

                
   If there
                      exists another single certificate status response
                      for a 

                
   target
                      certificate that is of interest, then proceed to
                      step 1. 

                
   Otherwise
                      the basic response is now processed.

                
 

                
 

                
32. Third
                    annex being proposed. This annex is important
                    because it provides guidance on how to build an OCSP
                    responder in the three cases. 

                    Many text portions are similar, but three full texts
                    are provided in order to provide a better clarity
                    for each of the three cases.

                
 

                
1.
                      Request processing by OCSP servers<=
/b>

                
=
 

                
   The behavior
                      of an OCSP server will be different whether the
                      OCSP 

                
   server is a
                      CA acting as an OCSP responder, is an OCSP
                      Responder 

                
   which
                      received a delegation from one or more CAs, or is
                      a locally 

                
   trusted
                      Responder.

                
=
 

                
1.1.

                      Processing by a CA acting as an OCSP responder

                
=
 

                
   The OCSP
                      responder SHALL maintain a list of entries. Each
                      entry 

                
   SHALL
                      contain:

                
=
 

                
     - the URI
                      associated to the OCSP responder, from which the
                      OCSP 

                
       reques=
ts
                      are received, 

                
=
 

                
     - the DN
                      from a CA,

                
=
 

                
     - an
                      issuing public key from a CA,
                
=
 

                
     - the
                      method(s) used to know for which subset of
                      certificates 

                
       issued=

                      by the CA it is responsible for, 

                
=
 

                
     - the
                      method(s) used to obtain the revocation status of
                      that 

                
       subset=

                      of certificates issued under that CA issuing
                      public key, 

                
       and

                
=
 

                
     - the
                      method used to gain access and sign with the
                      private key 

                
       corres=
ponding
                      to the issuing public key.

                
=
 

                
   For a given
                      URI value, the OCSP responder SHALL only use one
                      CA 

                
   key pair
                      value. 

                
=
 

                
   When it
                      receives an OCSP request on that URI, the OCSP
                      responder 

                
   SHALL handle
                      exceptions according to section 2.3. 

                
=
 

                
   If the OCSP
                      request contains the name of a requestor, the OCSP
                      

                
   responder
                      SHALL verify whether there exists a locally
                      defined rule 

                
   which
                      regulates access control.  If this rule
                      exists, it SHALL be 

                
   followed.

                
=
 

                
   Then, for
                      each target certificate, the OCSP responder SHALL
                      verify 

                
   whether both
                      the hash of the issuer's DN and the hash of the
                      issuer 

                
   public key
                      which are present in the request are eligible to a
                      

                
   locally
                      defined rule which indicates that the OCSP
                      responder is 

                
   responsible
                      to provide the revocation status of that target =


                
   certificate.  If this rule
                      exists, it SHALL be followed.
                
=
 

                
   Otherwise,
                      the OCSP responder SHALL determine whether it is 

                
   responsible
                      to provide the revocation status of that target =


                
   certificate
                      according to the following rule.

                
=
 

                
   For each
                      target certificate, the OCSP responder SHALL
                      verify whether 

                
   both the
                      hash of the issuer's DN and the hash of the issuer
                      public 

                
   key which
                      are present in the request match respectively with
                      the DN 

                
   and the hash
                      of the public key of contained in an entry from
                      the 

                
   list of
                      entries maintained by this OCSP responder. 

                
=
 

                
   When there
                      is no match, then the OCSP responder SHALL
                      indicate the 

                
   "unknown"
                      status and proceed with the next target
                      certificate from 

                
   the OCSP
                      request.

                
=
 

                
   When there
                      is a match, then the OCSP responder SHALL use the
                      serial 

                
   number of
                      the target certificate that is present in the
                      request and 

                
   determine
                      the revocation status of that certificate
                      according to 

                
   the
                      method(s) defined in the entry. 

                
=
 

                
   When the
                      revocation status is provided by the server using
                      a real 

                
   time access
                      to a database of revocation statuses of issued <=
/o:p>

                
   certificates,
                      then the thisUpdate field SHALL be present in the

                
   SingleResponse

                      response whereas the nextUpdate field SHALL be <=
/o:p>

                
   missing. 

                
=
 

                
   Otherwise,
                      both the thisUpdate and the nextUpdate fields
                      SHALL be 

                
   present in
                      the SingleResponse. 

                
=
 

                
   The time at
                      which this response will be signed MUST be
                      indicated in 

                
   the
                      producedAt field from the SingleResponse.<=
/span>

                
=
 

                
   If a
                      singleRequestExtensions is present in the request
                      it MUST be 

                
   processed.

                
=
 

                
   If there is
                      another target certificate present in the request,
                      it 

                
   SHALL be
                      processed in the same way.

                
=
 

                
   If a
                      requestExtensions is present in the request it
                      MUST be 

                
   processed.

                
=
 

                
   The OCSP
                      response MUST be signed using the CA issuing
                      private key.

                
=
 

                
=
 

                
1.2.

                      Processing by an OCSP Responder=


                
=
 

                
   For each CA
                      from which the OCSP Responder has received a
                      delegation, 

                
   the OCSP
                      Responder SHALL maintain a list of entries. 

                
=
 

                
   Each entry
                      SHALL contain:

                
=
 

                
     - the URI
                      associated to this OCSP Responder, from which the
                      OCSP 

                
       reques=
ts
                      are received, 

                
=
 

                
     - the DN
                      from a CA,

                
=
 

                
     - an
                      issuing public key from a CA,
                
=
 

                
     - the
                      method(s) used to know for which subset of
                      certificates 

                
       issued=

                      by the CA it is responsible for, 

                
=
 

                
     - the
                      method(s) used to obtain the revocation status of
                      that 

                
       subset=

                      of certificates issued under that CA issuing
                      public key,

                
=
 

                
     - an OCSP
                      certificate, 

                
=
 

                
     - the OCSP
                      public key contained in that OCSP certificate, and

                
=
 

                
     - the
                      method used to gain access and sign with the OCSP
                      private 

                
       key
                      corresponding to that OCSP certificate.

                
=
 

                
   For a given
                      URI value, the OCSP Responder SHALL only use one
                      OCSP 

                
   key pair
                      value.  Th=
erefore
                      there cannot be two entries with the 

                
   same URI
                      value and a different OCSP public key value.

                
=
 

                
   NOTE: a
                      BasicOCSPResponse can only be signed using a
                      single private 

                
         <=
/span>key. 

                
=
 

                
   The OCSP
                      certificate SHALL be signed by the CA issuing
                      private key 

                
   which
                      corresponds to the issuing CA public key that is
                      in this 

                
   entry.
                
=
 

                
   When it
                      receives an OCSP request, the OCSP responder SHALL
                      handle 

                
   exceptions
                      according to section 2.3. 

                
=
 

                
   If the OCSP
                      request contains the name of a requestor, the OCSP
                      

                
   responder
                      SHALL verify whether there exists a locally
                      defined rule 

                
   which
                      regulates access control.  If this rule
                      exists, it SHALL be 

                
   followed.

                
=
 

                
   For each
                      target certificate, the OCSP Responder SHALL
                      verify 

                
   whether both
                      the hash of the issuer's DN and the hash of the
                      issuer 

                
   public key
                      which are present in the OCSP request match with
                      those 

                
   from an
                      entry.

                
=
 

                
   When there
                      is no match, then the OCSP Responder SHALL
                      indicate the 

                
   "unknown"
                      status and proceed with the next target
                      certificate from 

                
   the OCSP
                      request.

                
=
 

                
   When there
                      is a match, the OCSP Responder SHALL use the
                      serial 

                
   number of
                      the target certificate this is present in the OCSP
                      

                
   request to
                      determine the revocation status of that
                      certificate 

                
   according to
                      the method(s) indicated in the entry. 

                
=
 

                
   When the
                      revocation status is provided by the server using
                      a real 

                
   time access
                      to a database of revocation statuses of issued <=
/o:p>

                
   certificates,
                      then the thisUpdate field SHALL be present in the

                
   SingleResponse

                      response whereas the nextUpdate field SHALL be <=
/o:p>

                
   missing. 

                
=
 

                
   Otherwise,
                      both the thisUpdate and the nextUpdate fields
                      SHALL be 

                
   present in
                      the SingleResponse. 

                
=
 

                
   The time at
                      which this response will be signed MUST be
                      indicated in 

                
   the
                      producedAt field from the SingleResponse.<=
/span>

                
=
 

                
   If a
                      singleRequestExtensions is present in the request
                      it MUST be 

                
   processed.

                
=
 

                
   If there is
                      another target certificate present in the request,
                      it 

                
   SHALL be
                      processed in the same way.

                
=
 

                
   If a
                      requestExtensions is present in the request it
                      SHALL be 

                
   processed.

                
=
 

                
   The OCSP
                      response MUST be signed using the OCSP private
                      key.

                
=
 

                
   Unless there
                      is a local rule which states differently, for
                      every 

                
   target
                      certificate which matches both with the hash of a
                      CA DN and an 

                
   issuing
                      public key from an entry, the OCSP certificate of
                      that entry 

                
   SHALL be
                      placed in the certs field.

                
=
 

                
   It may
                      happen, that none of the target certificates from
                      the OCSP

                
   request
                      matches both with the hash of a CA DN and an
                      issuing public 

                
   key from an
                      entry.  In=

                      that case and unless a local rule states <=
/span>

                
   differently,
                      the certs field from the BasicOCSPResponse SHOULD
                      be 

                
   kept empty
                      (to limit the disclose of the names of the CAs
                      from which 

                
   the OCSP
                      Responder received a delegation from).

                
=
 

                
1.3.

                      Processing by a locally trusted Responder<=
/span>

                
=
 

                
   For each CA
                      for which the locally trusted Responder is 

                
   authoritative,
                      the OCSP Responder SHALL maintain a list of
                      entries. 

                
=
 

                
   Each entry
                      SHALL contain:

                
=
 

                
     - the URI
                      associated to this OCSP Responder, from which the
                      OCSP 

                
       reques=
ts
                      are received, 

                
=
 

                
     - the DN
                      from a CA,

                
=
 

                
     - an
                      issuing public key from a CA,
                
=
 

                
     - the
                      method(s) used to know for which subset of
                      certificates 

                
       issued=

                      by the CA it is responsible for, 

                
=
 

                
     - the
                      method(s) used to obtain the revocation status of
                      that 

                
       subset=

                      of certificates issued under that CA issuing
                      public key,

                
=
 

                
     - the
                      method used to gain access to the private key in
                      order to 

                
       sign t=
he
                      OCSP response. 

                
=
 

                
   For a given
                      URI value, the OCSP Responder SHALL only use one
                      private 

                
   key.  Therefore
                      there cannot be two entries with the same URI
                      value 

                
   and a
                      different method to gain access to the appropriate
                      private key.

                
=
 

                
   NOTE: a
                      BasicOCSPResponse can only be signed using a
                      single private 

                
         <=
/span>key. 

                
=
 

                
   When it
                      receives an OCSP request, the OCSP responder SHALL
                      handle 

                
   exceptions
                      according to section 2.3. 

                
=
 

                
   If the OCSP
                      request contains the name of a requestor, the OCSP
                      

                
   responder
                      SHALL verify whether there exists a locally
                      defined rule 

                
   which
                      regulates access control.  If this rule
                      exists, it SHALL be 

                
   followed.

                
=
 

                
   For each
                      target certificate, the OCSP Responder SHALL
                      verify 

                
   whether both
                      the hash of the issuer's DN and the hash of the
                      issuer 

                
   public key
                      which are present in the OCSP request match with
                      those 

                
   from an
                      entry.

                
=
 

                
   When there
                      is no match, then the OCSP Responder SHALL
                      indicate the 

                
   "unknown"
                      status and proceed with the next target
                      certificate from 

                
   the OCSP
                      request.

                
=
 

                
   When there
                      is a match, the OCSP Responder SHALL use the
                      serial 

                
   number of
                      the target certificate this is present in the OCSP
                      

                
   request to
                      determine the revocation status of that
                      certificate 

                
   according to
                      the method(s) indicated in the entry. 

                
=
 

                
   When the
                      revocation status is provided by the server using
                      a real 

                
   time access
                      to a database of revocation statuses of issued <=
/o:p>

                
   certificates,
                      then the thisUpdate field SHALL be present in the

                
   SingleResponse

                      response whereas the nextUpdate field SHALL be <=
/o:p>

                
   missing. 

                
=
 

                
   Otherwise,
                      both the thisUpdate and the nextUpdate fields
                      SHALL be 

                
   present in
                      the SingleResponse. 

                
=
 

                
   The time at
                      which this response will be signed MUST be
                      indicated in 

                
   the
                      producedAt field from the SingleResponse.<=
/span>

                
=
 

                
   If a
                      singleRequestExtensions is present in the request
                      it MUST be 

                
   processed.

                
=
 

                
   If there is
                      another target certificate present in the request,
                      it 

                
   SHALL be
                      processed in the same way.

                
=
 

                
   If a
                      requestExtensions is present in the request it
                      SHALL be 

                
   processed.

                
=
 

                
   The OCSP
                      response MUST be signed using the OCSP private
                      key.

                
=
 

                
   The certs
                      field may contain no, one or several OCSP
                      certificates 

                
   according to
                      local rules followed by the locally trusted
                      Responder.

              

          

        

      
      


      

      
Not broken.

      


      

      
/Stefan

      


      

      
        

          

            

                
 

                
 

                
End of
                    comments

                  

                


                  Denis

                  <=
/o:p>

                
 

               

          

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

      
    

    

  


--B_3444861647_28902524--



From Internet-Drafts@ietf.org  Thu Feb 28 09:04:40 2013
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 0263521F8C23; Thu, 28 Feb 2013 09:04:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level: 
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 UR4-L3OpKov1; Thu, 28 Feb 2013 09:04:39 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD5321F8C16; Thu, 28 Feb 2013 09:04:39 -0800 (PST)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.41
Message-ID: <20130228170439.20540.81109.idtracker@ietfa.amsl.com>
Date: Thu, 28 Feb 2013 09:04:39 -0800
Cc: pkix@ietf.org
Subject: [pkix] I-D ACTION:draft-ietf-pkix-rfc2560bis-14.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, 28 Feb 2013 17:04:40 -0000

--NextPart

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

    Title         : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
    Author(s)     : S. Santesson, et al
    Filename      : draft-ietf-pkix-rfc2560bis
    Pages         : 43 
    Date          : Feb. 28, 2013 
    
   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,
   and updates RFC 5912.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2560bis-14.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.

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

Content-Type: text/plain
Content-ID: <2013-02-28090439.I-D@ietf.org>


--NextPart--